Updated: Comment #1
Problem/Motivation
The content translation settings UI is a really complex and, most of all, dynamic UI. Enabling a checkbox, for instance, can make a new table in a different place show up (e.g. enabling translation for a certain entity type) or simply make other table rows show up (e.g. enabling translation for a certain entity bundle make its field translation settings show up in the same table).. Vice-versa, disabling checkboxes make the same elements hidden to the user.
Proposed resolution
These are really dynamic changes and we should inform screen reader users about them, otherwise they will have a lot of troubles understanding how the UI works. Luckily, we have a Javascript utility that has been created exactly for this purpose: informing screen reader users of dynamic content changes. It is the Drupal.announce() utility and the Content translation settings UI should leverage it whenever the UI changes dynamically.
Remaining tasks
TBD
User interface changes
Yes. Screenreader interface changes to announce parts that are live, when they change.
API changes
No.
Comments
Comment #1
YesCT CreditAttribution: YesCT commentedI saw Jesse Beach's presentation at Twin Cities Drupal Camp and she talked about announce and I thought of this configurations settings page too!
Seems like a good use of it.
I'll update the issue summary with some related issues.
Comment #2
YesCT CreditAttribution: YesCT commentedIs this a duplicate of (but a specific strategy suggestion for) #1854030: Add hint to translation settings page when tables appear off screen
We could do sighted hint in that issue, and audio in this one.
Comment #3
falcon03 CreditAttribution: falcon03 commented@YesCT: thanks for updating the issue summary.
Both issues are quite related, but they are very different at the same time. Screen reader users should be informed about these dynamic changes in any case, while sighted users need hint only in certain conditions. Also, screen reader users should be informed when new rows appear in the same table that the cursor is placed in, while this is not necessary for sighted users.
So, long story short, let's fix the behavior for screen reader users in this issue and for sighted users in the one you linked in the previous comment.
Comment #4
jessebeach CreditAttribution: jessebeach commentedAdding and removing rows from a table might be best addressed by adding aria-live to that table directly.
We could use
aria-relevant
and register foradditions
andremovals
from the table.That quote is from https://developer.mozilla.org/en-US/docs/Accessibility/ARIA/ARIA_Live_Re...
Comment #4.0
jessebeach CreditAttribution: jessebeach commentedadded related issues and got the issue summary template.
Comment #5
mgiffordWould be great to see this in 8.0, but not sure it's going to happen at this time.
Comment #6
mgiffordComment #7
mgiffordComment #23
mgiffordThis doesn't tie to status messages, but if the content isn't provided to the AT I'd put it under a failure of WCAG 4.1.2
https://www.w3.org/WAI/WCAG21/Understanding/name-role-value