Respec: ReSpec pill does not do A11Y stuff to announce opens / closes

[halindrome]

People using screen readers are unable to interact with the pill to detect warnings and errors.

[marcoscaceres]

D'oh. Looking forward to seeing how this stuff is wired up.

[halindrome]

Me too! I am bringing in some expert help from ARIA Editors.

On Wed, Jul 20, 2016 at 7:38 PM, Marcos Cáceres [email protected]
wrote:

D'oh. Looking forward to seeing how this stuff is wired up.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/w3c/respec/issues/884#issuecomment-234125225, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAfx8Kgm9nak6wAh8RHVVQ_MhfaESEgsks5qXr9pgaJpZM4JRAIR
.

Shane McCarron
[email protected]

[marcoscaceres]

@patrickhlauke, maybe you can help with this one?

[patrickhlauke]

i can help if you point me to a reduced test case showing a "pill"

[marcoscaceres]

If you "inspect element" on the pill on, for instance:
http://wicg.github.io/server-timing/

you can see the basic structure that is generated.

You can see the code that actually generates the pill here:
https://github.com/w3c/respec/blob/develop/js/core/ui.js#L112

And the code that fades the pill in and out is just some simple jQuery:
https://github.com/w3c/respec/blob/develop/js/core/ui.js#L135

[patrickhlauke]

ah, so the pill is the actual "ReSpec" button, the number of warnings/errors button, etc. ok, will have a look through

[patrickhlauke]

some issues right off the bat:

• the pill is generated at the very end of the document (while visually it's at the top-right). for keyboard users (with and without additional AT like screen readers) this means that they'll have to navigate the entirety of the document before reaching it; if possible, generate it at the start, rather than the end, of the document, so it comes first in the source/tab order
• the "ReSpec" button should have aria-haspopup="true" attribute to denote that, well, it has a popup menu; additionally, aria-expanded="false" when the menu is closed and aria-expanded="true" when open [edit: additionally, I'll leave this here too: [Aria-Controls is Poop](http://www.heydonworks.com/article/aria-controls-is-poop) ]
• [edit: the actual ReSpec menu seems adequate to me as is, but there are probably differing opinions; it could be aria-fied to be a "proper" menu with menu items https://www.w3.org/TR/wai-aria-practices-1.1/#menu ]
• the second button (with the number of errors/warnings) doesn't have a very informative label (arguably, this is not exclusively a problem for AT users, but all users...what's a red "3"? etc); ideally, make it more verbose for all users (e.g. "3 ReSpec Warnings"); perhaps adding it as a title to the button itself, but also - to ensure it's announced consistently for AT users, knowing that some AT don't always announce title - add it as an explicit `aria-label="3 ReSpec Warnings"
• for all dialogs/overlays that ReSpec generates, focus should be moved to the actual dialog programmatically (e.g. make the <h3>Warnings</h3> programmatically focusable with the addition of tabindex="-1", then once it displays fire the focus() method on that heading; then, focus should be handled to remain inside the dialog/overlay (so keyboard user isn't tabbing out of the dialog and back into the page behind the dimmed overlay); in addition, hide the rest of the page with aria-hidden="true"; see @rodneyrehm's http://allyjs.io/tutorials/accessible-dialog.html for a clean way to do this sort of thing (and perhaps the recent inert attribute and polyfill https://www.youtube.com/watch?v=fGLp_gfMMGU); also add an explicit "Close" button to those dialogs - in addition to allowing user to close with ESC;
• the "Search SpecRef" thing needs quite a bit of work: the initial form lacks a programmatic name/label for the text input (either use a <label for="...">, or an aria-label="Search term" on the actual <input>); use aria live regions to notify user that a search is being carried out, and once done that results are shown

[halindrome]

This is great feedback. @mcking65 is this the sort of thing you were looking for? @joanmarie do you have additional thoughts?

[patrickhlauke]

happy to take a crack at some of the easier bits, but the overall dialog/overlay handling and specref search would require some rather fundamental decisions (e.g. if you want to add helper libraries, or write your own custom code for it, etc) which are probably best left for you folks to decide on. let me know...

[patrickhlauke]

forgot to mention, regarding the dialogs:

• once the correct focus behavior for dialogs has been added (moving focus programmatically to the dialogs, keeping it in the dialogs), you'll also need explicit focus handling when the dialog is closed - focus needs to be programmatically moved to the trigger/button that activated the dialog in the first place

[marcoscaceres]

happy to take a crack at some of the easier bits, but the overall dialog/overlay handling and specref search would require some rather fundamental decisions (e.g. if you want to add helper libraries, or write your own custom code for it, etc) which are probably best left for you folks to decide on. let me know...

I would like to burn all the existing HTML that is there in a fire and redo it properly using menu or better stuff. The pill and popup also looks like 💩 right now, so would be great to improve that.... having said that, we could take an incremental approach to fixing all of the above.

[Swapnilr1]

I would like to work on this, incrementally.

[SuyashSalampuria]

I would like to take up the issue @marcoscaceres . Can you please guide me from which of these I should begin now

[marcoscaceres]

@SuyashSalampuria, I think the first is done. So, just start with the second... and have a read of the related 💩 article 😂 It should help if we need to restructure anything. To find where the pill is inserted, checkout src/core/ui.js . The structure there should be fairly obvious for how the ReSpec pill is generated.

[SuyashSalampuria]

* for all dialogs/overlays that ReSpec generates, focus should be moved to the actual dialog programmatically (e.g. make the `<h3>Warnings</h3>` programmatically focusable with the addition of `tabindex="-1"`, then once it displays fire the `focus()` method on that heading; then, focus should be handled to remain inside the dialog/overlay (so keyboard user isn't tabbing out of the dialog and back into the page behind the dimmed overlay); in addition, hide the rest of the page with `aria-hidden="true"`; see @rodneyrehm's http://allyjs.io/tutorials/accessible-dialog.html for a clean way to do this sort of thing (and perhaps the recent `inert` attribute and polyfill https://www.youtube.com/watch?v=fGLp_gfMMGU); also add an explicit "Close" button to those dialogs - in addition to allowing user to close with ESC;

@marcoscaceres Can you please help me by telling how can i find all the dialogs/overlays generated by respec.
Thanks in advance!!

[marcoscaceres]

@SuyashSalampuria sorry for the delay.

Each panel can be found here:
https://github.com/w3c/respec/tree/develop/src/ui

They add themselves like this, for example:
https://github.com/w3c/respec/blob/a1f5e8b975232fa7be323fedcefa2c69fa9fd8a8/src/ui/about-respec.js#L12-L17

Each panel is basically a bit of logic and templated HTML.

[ciradu2204]

@marcoscaceres, @halindrome , and @SuyashSalampuria is this issue still open? If not, what's left?

[SuyashSalampuria]

I think it is done and can be closed.
Is there still anything left @saschanaz @marcoscaceres

[marcoscaceres]

@ciradu2204, if possible, it would be great if you could compare what was suggested in https://github.com/w3c/respec/issues/884#issuecomment-242375658

And see if we addressed everything that @patrickhlauke had outlined there. There might be a few things we missed.

In terms of functionality, it's still buggy in Safari - but works well in Chrome. However, it doesn't work too well on mobile devices - because focus doesn't make much sense on a phone/tablet: right now, when the pill open, the first item gets highlighted as gray. That should probably only happen when there is an explicit focus.

As a nice to have, adding up/down key control on the menu would be really nice.

[saschanaz]

That should probably only happen when there is an explicit focus.

That's :focus-visible but sadly nobody supports that yet.