Re: Admin accessibility

[Thibaud Colas]

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
 
.
 
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  (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 
> 

Re: Fellow Reports - May 2020

[Mariusz Felisiak]

Week ending May 24, 2020.

*Triaged:*
https://code.djangoproject.com/ticket/31598 - Broken link in Django 1.4 
docs. (invalid)
https://code.djangoproject.com/ticket/31599 - Improve the performance of 
the autoreloader by ignoring third party packages. (wontfix)
https://code.djangoproject.com/ticket/31597 - "Clear all filters" link 
removes TO_FIELD_VAR and is always displayed in raw_id_fields popup. 
(accepted)
https://code.djangoproject.com/ticket/31601 - 
postgres_tests.test_search.SearchHeadlineTests fails on latest PostgreSQL 
versions. (accepted)
https://code.djangoproject.com/ticket/31600 - Calling .delete() on a 
queryset doesn't delete related objects. (invalid)
https://code.djangoproject.com/ticket/31603 - "Clear all filters" link 
removes ordering and search criteria. (created)
https://code.djangoproject.com/ticket/31605 - messages shortcuts will not 
process with whitespace. (needsinfo)
https://code.djangoproject.com/ticket/31607 - Subquery.__eq__() doesn't 
work properly for resolved subqueries. (created)
https://code.djangoproject.com/ticket/31608 - forms.DateTimeField parses 
ISO 8601 datetime with offset as aware when USE_TZ is False. (accepted)
https://code.djangoproject.com/ticket/31611 - Point Coords inputted using 
OSM map widget in Admin are wrong way round. (duplicate)
https://code.djangoproject.com/ticket/31609 - Add support for Table 
Function Model. (wontfix)
https://code.djangoproject.com/ticket/14357 - Prevent inappropriate 
order-based grouping on values+annotate queries (fixed)
https://code.djangoproject.com/ticket/31612 - Running tests with --keepdb 
messy to flush. (wontfix)
https://code.djangoproject.com/ticket/31614 - order_by() with expressions 
crashes on union() querysets. (accepted)

*Reviewed/committed:*
https://github.com/django/django/pull/12922 - Enabled ESLint's "eqeqeq" 
rule.
https://github.com/django/django/pull/12920 - Refs #12990 -- Added 
DatabaseFeatures.has_json_operators.
https://github.com/django/django/pull/12927 - Fixed #31577 -- Clarified 
docs about bounds of RangeFields.
https://github.com/django/django/pull/12929 - Fixed #31601 -- Fixed 
SearchHeadlineTests on PostgresSQL 9.6.18+, 10.13+, 11.8+, and 12.3+.
https://github.com/django/django/pull/12796 - Fixed #31504 -- Allowed 
calling makemigrations without an active database connection.
https://github.com/django/django/pull/12935 - Fixed #31591 -- Clarified 
"reverse" lookup name in making queries docs.
https://github.com/django/django/pull/12856 - Fixed #31410 -- Added system 
checks for invalid model field names in UniqueConstraint.
https://github.com/django/django/pull/12940 - Added Kyrgyz language.
https://github.com/django/django/pull/12934 - Fixed #31597, #31603 -- 
Corrected admin clear all filters link behavior.
https://github.com/django/django/pull/11247 - Fixed #30375 -- Added FOR NO 
KEY UPDATE support to QuerySet.select_for_update() on PostgreSQL.
https://github.com/django/django/pull/12910 - Fixed #31546 -- Allowed 
specifying list of tags in Command.requires_system_checks.

*Authored:*
https://github.com/django/django/pull/12932 - Fixed #31578 -- Dropped 
support for MySQL 5.6.
https://github.com/django/django/pull/12936 - Fixed #31607 -- Fixed 
evaluated Subquery equality.

Best regards,
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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/343a9f14-478a-4718-86a4-5ccd71b2f28d%40googlegroups.com.

Re: Admin accessibility

[Tom Carrick]

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 
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-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/be97c4e7-f961-4d46-998f-693ca6076f09%40googlegroups.com
> 
> .
>

-- 
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%3DMaG5C7hHJ%3DJZaLZ8DNsevZzr8hmJ%3Dd4S%3D1mmTsXkiyPZw%40mail.gmail.com.

Re: Admin accessibility

[Mariusz Felisiak]

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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/be97c4e7-f961-4d46-998f-693ca6076f09%40googlegroups.com.

Re: Admin accessibility

[Tobias Bengfort]

Hi,

felixxm proposed in https://code.djangoproject.com/ticket/31617 to add a
DEP for this. The more I think about it, the less I agree.

There is no DEP for security, usability, developer ergonomics or
anything like that, so why should there be one for accessibility?

Like with any of the other categories, there are laws and regulations
that define a lower bound, but more is always better. And like with the
other categories, there are ways to find issues (think fuzzers) but no
way to verify the absence of issues.

So I think accessibility issues should be handled much like security
issues: When we find one, we fix it as quickly as possible. If there is
a conflict, say between security and accessibility, we decide on a
case-by-case basis.

Concerning which standard we should target: Tom made the case to target
WCAG 2.1 AA. I have not noticed any disagreement in this thread and
completely agree personally. Also note that many national regulations
are based on WCAG. So this question seems to be answered.

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/1a86d2d0-b3a2-0c56-8e13-cc64a32bead4%40posteo.de.