Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Try ARIA role application on the writing flow area. #5807

Closed
wants to merge 2 commits into from

Conversation

afercia
Copy link
Contributor

@afercia afercia commented Mar 26, 2018

Please don't merge :)

As discussed during today's accessibility meeting on Slack, this PR aims to try the ARIA role="application" on the post content area for a series of A/B testing with assistive technologies users.

The role is set on the Gutenberg "writing flow" area (which includes the post title) to make sure the writing flow keyboard events work as expected with screen readers.

The role="application" could solve a series of issues (see for example #5709 ) but also introduce new ones, so some actual testing is definitely necessary.

@afercia afercia added the [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). label Mar 26, 2018
@mtias mtias added the [Status] In Progress Tracking issues with work in progress label Apr 2, 2018
@mtias
Copy link
Member

mtias commented Apr 2, 2018

Adding in progress so it's not merged by mistake.

@afercia
Copy link
Contributor Author

afercia commented Jun 22, 2018

Rebased on latest master.

@afercia
Copy link
Contributor Author

afercia commented Jun 22, 2018

I've just tested again this PR with Firefox and NVDA and the role=application does have a huge impact.

It is expected that role=application makes screen readers stop intercepting key strokes (this would actually solve some issues in Gutenberg). It is also expected that it makes tabula rasa of all the semantics within the element with role=application.

What I wasn't expecting is that, when inside the element with role=application, also the semantics of anything that is outside is not perceived at all. This means that, when operating inside the blocks, no semantics in the general layout, top toolbar, sidebar, etc. is perceived at all.

For example, when invoking the Elements List in NVDA there are no landmarks any longer. No headings at all. Navigation through headings and landmarks doesn't work. Potentially, any other screen-reader specific shortcut to navigate through content doesn't work at all.

Screenshot without role=application: I'm on a button in browse mode and the Elements Lists shows me all the landmarks:

screenshot 8

Screenshot with role=application: I'm on a button in browse mode: no landmarks except a footer (not relevant, it comes from embedded youtube video which has a div with role="contentinfo" and it's perceived because it's within an iframe):

screenshot 7

Basically (and considering just these two side-effects) there wouldn't be no way for screen reader users to jump from the blocks to the top bar or to the sidebar, which is essential to be able to operate on the blocks.

I haven't tested other potential side-effects but potentially there's a lot of them that could break interaction in a so severe way to make impossible to use the editor.

@aduth
Copy link
Member

aduth commented Sep 13, 2018

Is there still a relevancy / desire to continue the work here?

@aduth aduth added the [Status] Stale Gives the original author opportunity to update before closing. Can be reopened as needed. label Sep 13, 2018
@afercia
Copy link
Contributor Author

afercia commented Sep 14, 2018

This PR was mainly for testing purposes, the accessibility team wanted to test the behavior of assistive technologies when switching everything to role=application. Can be closed.

@afercia afercia closed this Sep 14, 2018
@afercia afercia deleted the try/role-application branch September 14, 2018 08:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). [Status] In Progress Tracking issues with work in progress [Status] Stale Gives the original author opportunity to update before closing. Can be reopened as needed.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants