Improve overall admin accessibility.

[Gustavo Siñovsky]

Continuing this​conversation, 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.

[Gustavo Siñovsky]

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

[Mariusz Felisiak]

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.

[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".

[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?

[Mariusz Felisiak]

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?

[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.

[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

[Nick Pope]

Replying to Sourabh Rana:

Please don't close tickets that have not yet been resolved.

[Muhammed Ali]

I'll like to work on the
"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."
portion of this issue, is that okay?

[GitHub <noreply@…>]

In a0d43a7a:

Refs #31617 -- Changed dark mode primary-fg to give higher contrast to secondary.

[GitHub <noreply@…>]

In 950d697b:

Refs #31617 -- Removed redundant title text in filter.html.

Unnecessary since 269a76714616fd7ad166a14113f3354bab8d9b65.

Title text should provide advisory information and should not be the
same or very similar to the element text.

[Sarah Abderemane]

Hi, I would like to check this part :

"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."

Should I open a ticket separately or I make a PR reference this ticket?

[Carlton Gibson <carlton@…>]

In 69918801:

Refs #31617 -- Added an id for helptext in admin forms.

[Thibaud Colas]

👋 I’ve finally been able to spend a bit of time looking at the accessibility of the Django admin, after spending most of my time on forms. I’ve opened three bug reports and a feature request.

My initial assessment is that there are _a lot_ of issues with the admin as-is. This raises a few questions for me:

1. Having a ticket so broad in scope as this one doesn’t seem very helpful. It’d take tens of hours just to report the issues, let alone agree on fixes and delivering them. If we want to have a long-term "umbrella" place to track many issues, would there be a better place than this ticket? Within the GitHub issues / PR paradigm I would normally be looking for a Projects board for this. Not sure what the Django / Trac equivalent is.
2. It’s unclear to me how helpful it is to report issues as tickets as I uncover them. My time might be better spent making a more traditional audit, which could then be broken up into more meaningful tickets.

I could make a spreadsheet (Google Sheets), reusing a ​template I have from Wagtail. This is simple but is quite specialized and lacks a few basic features (screenshots). We could use a service like ​Be Inclusive, whose founder let me know they would be interested to sponsor Django with free access to their service if the need arrives. Perhaps Django has other organisational tools in place to consider?

---

On the issues, to give a bit more information, at a high level:

• There are almost no landmark regions. This needs to be introduced for all pages throughout the admin
• There is surprisingly little usage of ARIA roles and attributes compared to the number of bespoke interactive elements in the admin. This suggests a lot of those elements are implemented in a way that only works for sighted users (and potentially keyboard users too). For example, InlineModelAdmin seems like something that ought to use ARIA.
• I can find a lot of contrast issues, particularly in dark mode.
• A lot of the admin seems to be overusing title attributes to provide basic tooltips. This means the contents of those tooltips is only available to mouse users and screen reader users, leaving keyboard and touch screen users out.

[Thibaud Colas]

Based on my assessment of this ticket about a year ago, I’d recommend closing. It has done its job of kickstarting Django’s accessibility efforts and admin improvements in particular. I don’t think it can help further: As others have mentioned, "improve admin accessibility" is way too broad to ever be "done". And as far as people coordinating, there are way better places than Trac comments.

[Mariusz Felisiak]

Agreed, let's close it.