Hi all, I am legally blind. Accessibility discussions tend to largely revolve around contrast and screen readers (which I do not use) as it’s easy to measure for (albeit poorly without actually trying to use a screen reader yourself, which nobody tends to do).
I am unsure if I have any valuable / unique perspective to share, and I probably don’t, but I am always happy to help. I have wanted an excuse to get involved in the framework's development and this would be as good a time as any. The one thing I will say (and this doesn’t come from any lived experience, rather what I’ve heard) is not to rely to heavily on automated accessibility metrics, especially when it comes to screen reader friendliness. An interface can tick all the automated boxes but still be terrible to use. Just as with other user interfaces, automation can only get us so far and additional manual checking would be worthwhile. Kye On 21 May 2020 at 9:33:51 pm, Tom Carrick (t...@carrick.eu) wrote: Hi Adam, > Which checker did you use? I had a brief check with a few. Firefox's devtools, Lighthouse, and WebAIM's WAVE browser extension. WAVE is quite nice in that it shows the problems directly on the page, but they all give more or less the same information. If Lighthouse can be integrated into the CI it seems the most logical option. Lighthouse also gives a 0 - 100 score metric for each page, which would be nice as part of a coverage-style CI process, i.e. the score can remain the same or increase, but a decrease will fail the test. > Would you be able to work on this on an ongoing basis? If you know others who are interested, perhaps we could even form a Django a11y team, just like we have an i18n team. I'm happy to work on this on an ongoing basis. Thinking over the idea of an a11y team, at first I thought it would have too narrow a scrope as it only really concerns the admin, but I realised it also concerns the docs, the djangoproject website, and other sites under the django org (django-people and so on), so perhaps it's worth doing. That said, I don't have any physical disabilities to speak of. My eyes are pretty bad, small text can be a problem, but that's about it. It would be good to get some feedback from people that this directly affects, but I don't know of many. It'd also be hugely beneficial of course if any a11y team includes people with physical disabilities or at least experience with it. I can only immediately think of one person in the Django community that might fit, so I will reach out to them and ask if they'd be interested in giving any input here, but more voices would be useful. For the low-hanging fruit, I will run Lighthouse on some more pages and write some tickets up when I get some time, hopefully over the weekend. Cheers, Tom On Thu, 21 May 2020 at 14:04, Adam Johnson <m...@adamj.eu> wrote: > Hi Tom > > It's a laudable goal to make the admin accessible. Thank you for doing the > research on currently laws and guidelines. > > I haven't audited the entire admin, but I have run a checker through some >> pages. >> > > Which checker did you use? I see Google's Lighthouse checks for many > accessibility issues: https://web.dev/lighthouse-accessibility/ > > I think fixing any "low hanging fruit" would be acceptable PR's right now. > > Setting a target and keeping to it would be harder though. Documentation > is easy to write, but it can easily be forgotten/ignored, so I'd prefer a > CI solution. One potential CI solution is running admin tests through the > Lighthouse CLI. > > There will certainly add an ongoing maintenance cost. Would you be able to > work on this on an ongoing basis? If you know others who are interested, > perhaps we could even form a Django a11y team, just like we have an i18n > team. > > On Tue, 19 May 2020 at 12:11, Tom Carrick <t...@carrick.eu> wrote: > >> Sorry, long post incoming. >> >> The admin currently has some accessibility issues. Not a huge amount, >> actually, but they should be fixed regardless. I hope I don't need to >> convince anyone here of the importance of accessibility, but I'll try to >> make the case as briefly as possible for the benefit of the wider community. >> >> There is a trend towards stronger accessibility laws - there is a good >> roundup of them here: https://www.w3.org/WAI/policies/ - and I'll come >> back to this later. Most of these cover the public sector and small >> segments of the private sector, but there's also an overview of some laws >> used against private entities more generally here: >> https://en.wikipedia.org/wiki/Web_Content_Accessibility_Guidelines#Legal_obligations >> >> I should make it clear that I'm not a lawyer and have no idea if any of >> this would apply to the admin, since it's not intended for general >> consumption, so I think I'd rather make this point: Developers and other >> people using the admin - "staff users" of some kind - can have disabilities >> too, and we should be catering for them, especially since the remedies are >> not at all difficult. It's also worth pointing out that accessibility >> improvements almost always improve the general experience. For example, >> making sure everything is easily accessible for keyboard only users is also >> beneficial to power users. Better contrast and larger fonts are more >> legible for everyone, not just for those with low vision, etc. >> >> So I think the place to start here is to decide on a guideline to aim >> for, and I'm pretty convinced at this point that WCAG 2.1 at Level AA is >> the way to go: https://www.w3.org/TR/WCAG21/ >> >> Why not AAA? Well, it's really hard / time-consuming. For example, users >> have to be able to select their own foreground / background colours, if a >> user's session expires, they need to be able to login in again and pick off >> where they left off (forms filled, etc.), and more. Moreover, every law >> I've looked at seems to use WCAG 2.0 (2.1 is just a couple years old and is >> backwards compatible) at Level AA, so this seems like the target to aim >> for. I don't see a reason to not make specific improvements to AAA where >> they're relatively simple, however, but my point is that we should make AA >> a minimum requirement. >> >> So if that is accepted, we need a few things: >> >> 1. Document it and update the contributing docs. >> 2. Audit the admin properly. >> 3. Fix any issues. >> 4. Make sure reviewers have this in mind for admin changes (I'm not sure >> if there's any CI solution for this, but it would be nice to have). >> >> I haven't audited the entire admin, but I have run a checker through some >> pages. The main issues are with contrast and small font sizes, and the >> changelist also seems quite painful. For example, there are no labels on >> the checkboxes to select rows, which is going to be pretty hard to >> understand and use if you're blind. A quick aria-label can fix this without >> affecting it for sighted users. >> >> Another issue here is harder to solve, it requires two tabs to move to >> another row of the change list in the default state (one for the checkbox, >> one for the link to the change form page). If you have editable fields in >> the change list, it's another tab for each. It would be nice to be able to >> use vim keys to move up and down rows, perhaps be able to hit * to select a >> row for an action. In general, keyboard shortcuts would be handy elsewhere >> too. It would be nice to be able to hit a key to open the nav sidebar which >> also sets tab focus on the first link, for example. >> >> But these details aren't the point of the post. The point of the post is >> to decide if this is worth it (clearly I think it is), and how to move >> forwards on it. Any thoughts? >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers (Contributions to Django itself)" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to django-developers+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/CAHoz%3DMaQhWCtH%2BRZrp8JuXOyPFghAk7GVsJQPD15YHE9DUzQyw%40mail.gmail.com >> <https://groups.google.com/d/msgid/django-developers/CAHoz%3DMaQhWCtH%2BRZrp8JuXOyPFghAk7GVsJQPD15YHE9DUzQyw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > > > -- > Adam > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/CAMyDDM3BFwKmXDw7rR46QswdA%2BKbGWM7euz1Zujt%2BtVwhgHKjw%40mail.gmail.com > <https://groups.google.com/d/msgid/django-developers/CAMyDDM3BFwKmXDw7rR46QswdA%2BKbGWM7euz1Zujt%2BtVwhgHKjw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAHoz%3DMajRhzFMPKHXYQuOSouk4jej%2BwQ%2B%2B7JrtWQv02P4ZTQVQ%40mail.gmail.com <https://groups.google.com/d/msgid/django-developers/CAHoz%3DMajRhzFMPKHXYQuOSouk4jej%2BwQ%2B%2B7JrtWQv02P4ZTQVQ%40mail.gmail.com?utm_medium=email&utm_source=footer> . -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CANK-ykkkuBOGGBBFOhP7BViN8zk5_HCBnw-TUVWZHoUwduTwhA%40mail.gmail.com.
