Hi Tom, It’s exciting to see this getting started! To me a DEP would be highly beneficial, because there is a lot to this that goes beyond finding and fixing individual issues – it’s more about detailing the a process for parts of Django to stay accessible over time. Here are things I’d suggest to cover, in addition to your list:
- Going further than the targeted standard and tests in CI – outline clear steps developers should take when testing their work: using developer tools, screen readers, etc. It’s not practical to just state the standard as WCAG is quite big, and open to interpretation. And CI testing will never be enough to reach any degree of compliance. - I’m not familiar with Django’s development process but generally I would recommend to use a combination of linting, browser extensions, manual testing instructions – and CI tests. - If the accessibility team was to cover more than the Django admin, I think it would be worthwhile to also include accessibility of sites built with Django. Django is largely unopinionated about markup, but I remember its forms markup not being particularly good for screen readers, and the HTML code snippets in the docs would also be worth reviewing. - Same goes for admin docs – not too familiar with them myself so I’m not sure whether they are considered to be part of the admin, or separate. - I wouldn’t find it surprising if an audit of the Django admin turned up a lot of issues. IMHO part of the DEP should cover how to manage this – whether individual issues warrant individual tickets or not, and how to prioritize the issues if relevant. Which kinds of issues are likely to need design input. If the DEP is done first, also talk about what kind of auditing would be valuable, and how to make it happen. To help with the initial audit and prioritisation of issues, I would suggest to first start by creating a map of all of the parts of the Django admin that are to be audited – list all of the individual pages, and all of the states the pages can be in (success, error, loading – empty content / some content / paginating, etc). I also find it worthwhile to add a succinct definition of how each of those pages is likely to be used – for example things that are only configured once for a site’s lifetime are presumably not as worth improving as a screen a user would see on a daily basis. Here is an example in practice: https://docs.google.com/spreadsheets/d/1rTMilzKhcb43Y3fZKGJJeoKWLCR00bfgwVB9f6OaC2U/edit <https://docs.google.com/spreadsheets/d/1rTMilzKhcb43Y3fZKGJJeoKWLCR00bfgwVB9f6OaC2U/edit#gid=0>. This can also be used to track the auditing effort, and form the basis of an automated test suite for CI (or simply repeat testing). Finally, consider ATAG2.0 <https://www.w3.org/TR/ATAG20/> (Authoring Tool Accessibility Guidelines) compliance additionally to WCAG. At a high level, ATAG is made of two parts: - Part A: Make the authoring tool user interface accessible. That sounds like what we’re discussing here. - Part B: Support the production of accessible content. That’s a whole other topic but feels relevant too. ATAG is nowhere near as well known / established / easy to test for, but it feels very relevant to the Django admin in particular, and I’m sure there will at least be some useful bits to consider in its success criteria Hope this helps! Thibaud On Monday, May 25, 2020 at 11:56:39 AM UTC+1, Tom Carrick wrote: > > Hi, > > Thanks for the feedback. I had thought about a DEP when I was writing up > the original post actually, I just wasn't sure what it should contain. Here > are my thoughts, based on the feedback so far: > > - Defining a standard to target. > - Forming an a11y team that covers the django admin and all sites in the > django github organization, and defining its role, membership, etc. > - Deciding on a CI process > - An outline of current issues and how to solve them. > > If anyone can think of anything else, please let me know. If/when there's > a consensus I'll start writing a draft. > > Mariusz, I mentioned this in the original post, but > https://www.w3.org/WAI/policies/ has a good overview of laws and EU > directives in this area. From my browsing through, it seems that they all > either, have their own national standard, or are using WCAG 2.0/2.1 AA. > Since we probably don't want to define our own standard, I think AA is the > way to go. This seems to also be the recommendation I hear from people in > the accessibility field working on regular websites. AAA seems to be more > suited for very specialist sites that explicitly target disabled people. > > Most of AAA is completely feasible for us, but there are some reasons it > would be difficult: > > - All language needs to be at a lower secondary education level, or have > an alternative that is. This doesn't seem feasible, for e.g. the > documentation. > - Users that are logged out need to be able to resume their session where > they left off after logging in, with all form fields filled, etc. > > There are others that are difficult, but I don't think any apply to us > currently. > > Cheers, > Tom > > > On Mon, 25 May 2020 at 11:09, Mariusz Felisiak <felisia...@gmail.com > <javascript:>> wrote: > >> Hi Tobias, >> >> I'm not a WCAG expert, and it's not clear to me what steps we would >> like to take. In the ticket we have only steps describes as *"very >> basics which should include"*, so I can imagine that's not all we need >> to do to be WCAG 2.1 compliant on AAA, AA or A level. As far as I'm >> concerned WCAG is quite massive. Moreover if we want to make changes in CI >> we should discussed available tools, etc. We can change colors but what >> next? We will be not able to guarantee that the contrast of all elements >> remains appropriate, we cannot do this manually. >> >> Best, >> Mariusz >> >> -- >> 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-d...@googlegroups.com <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/be97c4e7-f961-4d46-998f-693ca6076f09%40googlegroups.com >> >> <https://groups.google.com/d/msgid/django-developers/be97c4e7-f961-4d46-998f-693ca6076f09%40googlegroups.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/148d658c-2062-4973-ac6c-9f1abd5e95e3%40googlegroups.com.
