Hi there,
I think it's a great initiative, even if as a person with physical disabilities, I've never been issues to use any kind of software. I would be happy to contribute but I'm not aware of any tool that can be integrated in any continuous integration system. Whenever I've been working in projects that implied accessibility requirements, I've always used "manual" processes to verify the web accessibility. Let me know if a team is formed for this purpose. I think I could contribute a few hours of work. Personally, I think that, as Adam says, it would be not difficult to amend the “low hanging fruits“, such as: - alt text for images - semantic use of headings (h1, h2, …) - avoid use of style tags inside the html code - lack of contrast in texts Web accessibility tools I'm aware of: - http://colorsafe.co/ - Design accessible color palettes based on WCAG Guidelines - https://achecker.ca/checker/index.php - Web Accessibility Checker - http://www.niquelao.net/wcag_contrast_checker/ - color contrast checker - http://webaim.org/resources/contrastchecker/ - color contrast checker - http://www.visionaustralia.org.au/info.aspx?page=1812 - Correct use of tables Kind regards El dimarts, 19 maig de 2020 13:12:17 UTC+2, Tom Carrick va escriure: > > 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/25ae3ff2-9a9b-4af0-97d2-3cf654ccbed1%40googlegroups.com.
