Opened 3 months ago

Last modified 11 days ago

#31617 new New feature

Improve overall admin accessibility.

Reported by: Gustavo Siñovsky Owned by:
Component: contrib.admin Version: master
Severity: Normal Keywords: accessibility, ui, ux, admin
Cc: Triage Stage: Someday/Maybe
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: yes UI/UX: yes

Description

Continuing thisconversation, there are many small tasks that can be carried out rather easily which would vastly improve the experience of using the admin site from an accessibility standpoint. It's important to offer at least the very basics which should include:

  • Making the admin keyboard-only friendly: this means making every interactive element focusable.
  • Adding appropriate ARIA labeling and roles to any element that requires it, this would have to be done in a way supporting localization.
  • Making sure the hierarchy of headings makes sense semantically, this means using h1-h6 tags in their appropriate level: h1 for primary titles only, h2 only for secondary titles and so on.
  • Make sure the contrast between foreground and background colors meets standard thresholds
  • Automate part of the process by including tools such as aXe into the CI pipeline, to make sure new changes come with at least the very basic accessibility considerations.

By doing this we make it easier to screen readers and only-keyboard users to effectively make use of the django admin site.

This proposal in no way means to be a final solution, but rather an intention to kickstart the conversation about the importance on providing access to the django admin site to everybody.

Attachments (1)

example.jpg (78.2 KB) - added by Gustavo Siñovsky 3 months ago.
Example of an auditing tool running on a page from the django admin, showing many easy to fix violations in tems of accessibility

Download all attachments as: .zip

Change History (7)

Changed 3 months ago by Gustavo Siñovsky

Attachment: example.jpg added

Example of an auditing tool running on a page from the django admin, showing many easy to fix violations in tems of accessibility

comment:1 Changed 3 months ago by felixxm

Summary: Improve overall admin accessibilityImprove overall admin accessibility.
Triage Stage: UnreviewedSomeday/Maybe
Version: 3.0master

Thanks for this ticket. It's a big change and IMO we need a DEP if we want to move it forward. There is many unanswered questions that should be discussed in DEP before we will start. For example, we want to make the admin accessible, but what standard we will target? (probably WCAG 2.1), if yes then at which level? (A/AA/AAA). What with national standards, e.g. EU directives? etc.

comment:2 Changed 3 months ago by Tobias Bengfort

My pull request about color contrast was recently rejected. I agree that there are many unanswered questions and a DEP is probably the right way to go. However, I don't agree that any accessibility related improvement should wait for that. If there is too little color contrast that is a bug that needs to be fixed ASAP, not "someday/maybe". I think the better approach would be:

  • Do low hanging fruits as soon as possible
  • Come up with an overall strategy in parallel

Of course it is open to debate what constitutes a "low hanging fruit" (and if my color changes fall into that category). But I would strongly argue that this should be decided on a case-by-case basis and not a blanket "nothing will be merged until there is a DEP".

comment:3 Changed 3 months ago by Claude Paroz

I do agree with Tobias here. Typically, improving color contrast of the admin is a no-brainer and I'm not sure a DEP will bring anything for that. Maybe create a separate ticket for it?

comment:4 Changed 3 months ago by felixxm

This is a new feature and we have plenty of time to the feature freeze for Django 3.2 (January 14, 2021). Is there any reason to do this multiple times on master?

comment:5 Changed 3 months ago by Tom Carrick

I'll make a similar post on the mailing list soon, but my initial thought is that this ticket is too big to ever get closed. I'm not sure if that's a problem or not, I don't know if we use tickets to track problems that are unlikely to be solved. I agree with Felix that we need a DEP, but I also agree that we can tackle some low hanging fruit (making sure all the form elements have either labels or aria-labels is a good first step.

I actually don't think fixing the contrast is a good first step, because it needs input more design-minded people, it's actually quite difficult to keep the existing colours while also increasing the contrast to a good level.

I think targeting 3.2 to get the basics done and get a CI solution working makes sense.

For example, we want to make the admin accessible, but what standard we will target? (probably WCAG 2.1), if yes then at which level? (A/AA/AAA). What with national standards, e.g. EU directives? etc.

I covered this in the mailing list post, but I'm gunning for WCAG 2.1 AA, this is what every law and EU directive I've seen is using (that or their own internal standards), and seems like the general recommendation from people in the field.

Last edited 3 months ago by Tom Carrick (previous) (diff)

comment:6 Changed 3 months ago by Gustavo Siñovsky

If we intend to create a formal and extensive backbone to this initiative from the get go, we are never going to be done. I also agree a sensible first step would be to create a very basic set of guidelines (I also gun for WCAG 2.1 AA, as well as targeting 3.2 and get a very simple CI solution working), which definitely would be better than nothing (which is what we currently have), and then work our way up from there towards more formal efforts in subsequent tickets

Note: See TracTickets for help on using tickets.
Back to Top