On Thursday, 17 June 2021 at 14:01:15 UTC+5:30 Thibaud Colas wrote:
> Thank you all for the feedback :) I have a feeling it might indeed be > easier for me to propose this for review in the form of a pull request to > the Django docs, as I have quite a clear idea of what I’d propose at a high > level. > > On testing tools, yes, both Pa11y and Lighthouse would be worth > considering. They both use Axe to do the actual checks, which means results > will be largely comparable between Lighthouse, Pa11y, and Accessibility > Insights. I’ve set up automated tests for the Django admin based on Pa11y + > Lighthouse, which you can see here: django_admin_tests > <https://github.com/thibaudcolas/django_admin_tests>. My preference as > "the one tool" to recommend still is Accessibility Insights, as it contains > a good mixture of automated and semi-automated checks, as well as a very > thorough wizard to guide people through manual checks. > I love the Django admin accessibility tests and repo that you made. The demo report looks pretty decent to me! I think that would be super useful when issues are created and for fixing the issues. There's also this web app https://beinclusive.app/ which allows you to manage accessibility audits better which might be helpful in some form when we have a concrete accessibility audit. Might I also add that once we have a decent accessibility improvement, we add something like accessLint <https://accesslint.com/> in the CI to assure that future PRs don't have any glaring accessibility issues? > > > I wanted to check the issue on password UX but maybe I can help on > others things related to this before. Tell me what do you think. > > There’s quite a lot of ground to cover, so any and all help is welcome :) > If you’re interested in UX work generally – once we start properly auditing > the Django admin, reporting issues will be straightforward enough, but > proposing solutions will be much harder. Anyone with a good mix of Django > and UX expertise will be in a great position to contribute. For example, > last week I audited django-postgres-metrics > <https://www.youtube.com/watch?v=8pegTdRaUDg> and found a few issues > relating to table sorting. Fixing those issues could be an opportunity to > generally improve the table sorting UX for all. > > > I am not completely sure about the definition of an "authoring tool", > but it might make sense to consider django as a whole as such an > authoring tool, not just the Django admin. ATAG A. (Make the authoring > tool user interface accessible) would then only apply to Django admin, > but ATAG B. (Support the production of accessible content) would apply > to everything. > > Indeed! There are a few things that likely couldn’t apply (Guideline > B.3.2: Assist authors in repairing accessibility problems > <https://www.w3.org/TR/2015/NOTE-IMPLEMENTING-ATAG20-20150924/#gl_b32>) > but they feel like they might be the exception rather than the rule. It’s > certainly a helpful lens to consider accessibility improvements through. > > Best regards, > > Thibaud > > On Tuesday, 15 June 2021 at 18:19:41 UTC+1 Tobias Bengfort wrote: > >> Hi Thibaud, >> >> thanks for the follow up. +1 on basically everything you wrote! >> >> On 15/06/2021 02.59, Thibaud Colas wrote: >> > This distinction between "sites built with Django" and the "Django >> > admin" highlights an important point, which is that for lots of sites >> > the Django admin would be what accessibility standards call an >> authoring >> > tool. There is a separate standard for authoring tools that builds upon >> > WCAG 2.1: ATAG 2.0. I think we should also explicitly aim for >> compliance >> > with ATAG 2.0 wherever possible, as it has a lot of useful guidelines >> we >> > could follow for the Django admin. For Django itself, there might be >> > very little to do to implement those guidelines, but for the wider >> > ecosystem of CMS-like features in Django it would make a clear >> > difference if Django was clearly defined as an authoring tool. WCAG >> > itself is a very thin baseline as standards go, so anything that goes >> > beyond it is well worth considering in my opinion. >> >> I am not completely sure about the definition of an "authoring tool", >> but it might make sense to consider django as a whole as such an >> authoring tool, not just the Django admin. ATAG A. (Make the authoring >> tool user interface accessible) would then only apply to Django admin, >> but ATAG B. (Support the production of accessible content) would apply >> to everything. >> >> > * *Which automated or semi-automated testing tools to use when testing >> > changes to Django*. My go-to is anything Axe >> > <https://www.deque.com/axe/>-based, as it’s ubiquitous, and has very >> > few false positives. In particular with the Accessibility Insights >> > <https://accessibilityinsights.io/> browser extension. >> >> AFAIK the accessibility checker in chrome's lighthouse is also based on >> Axe. As it is already built into a very popular browser this might lower >> the threshold for testing even further. >> >> tobias >> > -- 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/851a1cc3-ef31-4e77-88de-5216c8f62905n%40googlegroups.com.
