Hi django-developers, This is a long-overdue follow up to DEP 11 <https://github.com/django/deps/blob/main/accepted/0011-accessibility-team.rst> and the creation of Django’s accessibility team. As part of implementing what this DEP outlines, we need to discuss what accessibility standards should apply to Django, among other things. In my opinion this is both a matter of deciding what pre-existing standards / guidelines would be relevant in theory, but also how to make sure whichever ones we choose are achievable to follow in practice. We need to find some consensus on what Django as a project should aim for, so our team and all contributors can take it into consideration, and in particular so we can document what we want to commit to as a reference for accessibility work.
Here are accessibility team responsibilities <https://github.com/django/deps/blob/main/accepted/0011-accessibility-team.rst#responsibilities> I would like to bring up for discussion in particular: - *Deciding on any relevant accessibility guidelines to follow, such as WCAG, and at which conformance level.* - *Coordinating regular manual accessibility audits on all relevant projects.* - *Writing and maintaining documentation relating to accessibility, such as a statement of commitment to accessibility issues, and contribution guidelines.* Now I’ll try to outline what I’d suggest for each area, which people here are very welcome to disagree with as relevant. Accessibility guidelines In my opinion, the most important standard for *_sites built with Django_* is WCAG 2.1, AA level. Anything resulting in AA level issues should be considered as a bug. Wherever possible, we should also strive to not get in the way of sites built with Django aiming for AAA level compliance. For the Django admin, I would recommend the same target of WCAG 2.1 AA level as a baseline, aiming for AAA wherever possible. For example, the link text issue discussed in Default change password UX: area for improvements <https://groups.google.com/g/django-developers/c/8_lJUFRv2V4/m/O2cZAqpwAQAJ> is a case where I’d expect us to want to follow WCAG SC 2.4.9: Link Purpose (Link Only) <https://www.w3.org/WAI/WCAG21/Understanding/link-purpose-link-only.html>, even though it’s level AAA. 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. For everything else within the Django ecosystem – the documentation, the djangoproject.com website, the bug tracker, IRC, plain-text documentation, etc. – we should follow the exact same standard. I would also really like to see the same standard being explicitly recommended for consideration for third-party Django projects (similarly to Django projects wanting to provide the same level of browser and language support as Django itself, I imagine). This probably warrants a separate conversation but I would also recommend the Django Software Foundation explicitly mandating the same standard for any project or event it endorses. It’s worth mentioning as well that the next version of WCAG, WCAG 2.2, is due to be released by the end of 2021. I’d recommend we don’t aim for support with WCAG 2.2 right now, but do so as soon as it’s released. In the meantime, we should also consider any WCAG 2.2-only guideline wherever reasonable (for example in audits, design of new features, etc.). Contribution guidelines Aiming for compliance with specific standards is good, but we shouldn’t expect Django contributors to be familiar with WCAG, or any other standard. I think it’s important we update the contribution guidelines to propose practical support targets: - *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. - *Which assistive technologies should we explicitly strive to test Django with, so contributors have clear guidance on how to test their changes*. For example here are the testing guidelines for public sector sites in the UK <https://www.gov.uk/service-manual/technology/testing-with-assistive-technologies> . - *Whether / how best for the accessibility team to be involved* with UX or design changes in Django & other projects, or other changes that would require accessibility considerations. Manual audits This would be very dependent on the above two points. Beyond this, it would be good to discuss what audit methodologies would be satisfactory (whole of the admin, sampling, what demo site to test, etc.) – and what would be the most useful on the reporting side. Short-term actions There are a couple more things I wanted to raise for others to feed back on, relevant to all of the above but that I think would make a bigger difference in the short term: - Currently I’m only able to test Django with VoiceOver on macOS, and as such can’t test with a lot of other popular assistive technologies. There is a SaaS called Assistiv Labs <https://assistivlabs.com/> that provides VMs with pre-installed assistive technologies, with a free plan for open-source projects. Could we ask them to sponsor Django? I imagine this might be more of a question for the relevant DSF team(s) but wanted to see what people thought here first. Note this isn’t specific to my situation – assistive technologies are very segmented by operating system, so we would need to find strategies to test across different ones one way or another. - There is an EU-funded research project on authoring tools’ accessibility currently under way, We4Authors Cluster <https://accessibilitycluster.com/>. I’m interested in filling out a survey from this project <http://surveys.funkanu.se/s3/cluster-project-survey> as a way to assess Django’s position with their early findings. I don’t think this engages anyone in any way but thought it would be good to bring it up nonetheless in case it raises any red flags. --- How does all of this sound? Anything I missed that should be brought up at the same time? I appreciate this might be a lot of things to comment on over email – assuming there is some high-level agreement, it might be easier for people to review as PR(s) to the Django contributing docs, but thought I’d try here first. Best regards, Thibaud -- 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/9d60fd5a-56ea-4aa7-b5d8-0037515e3aa9n%40googlegroups.com.
