653567 - GCLI should be checked for accessibility

Status: RESOLVED FIXED

(DevTools :: General, defect)

Description

[Joe Walker [:jwalker]]

Things to be considered:
- How do we ensure that the correct hints are voiced to the user
- How do we enable the user to ask for more detailed help

Comment 1

[Joe Walker [:jwalker]]

David: The feature page for GCLI is here: https://wiki.mozilla.org/DevTools/Features/GCLI

If you'd like to discuss it's purpose or how it works that's fine. I will setup a demo for you too.

Essentially, tell me what you need, and I'll see that it happens.
Thanks

P.S. Before I forget (and this is as much a note to self as anything) there is a current bug (bug 653568) where nodes are re-created far more frequently than they should be. That's something that will affect accessibility.

Comment 2

[alexander :surkov (:asurkov)]

It makes sense to show a demo to Marco actually.

Comment 3

[Joe Walker [:jwalker]]

I've uploaded a new demo of the command line that can be run easily in a web browser, which I hope will make it easier to work out what we need to do to make the new command line accessible. See https://people.mozilla.com/~jwalker/gcli/build/nohelp.html

We've cut the process of getting GCLI into Firefox into 2 sections, the first is just the command line without any popup help (hence the URL above) The second section adds popup help - see https://people.mozilla.com/~jwalker/gcli/build/index.html for an example.

The second section is more work both from an accessibility and localization POV. Initially I'm only looking for assistance with making the version without the popup help accessible, but I hope the second part will follow soon.

David/Marco - what do I need to do to make this properly accessible?
Thanks

Comment 4

[David Bolter [:davidb] (NeedInfo me for attention)]

Sorry Joe, this bug got lost in my stack.

I'm going to like using this tool! Let's definitely make sure everyone can.

(In reply to comment #1)
> David: The feature page for GCLI is here:
> https://wiki.mozilla.org/DevTools/Features/GCLI

Please note in general I'm hoping that at Mozilla we will make accessibility a release requirement for all features with UI. A CLI should be accessible. (I realize this is tricky when something starts out as experimental)

(In reply to comment #3)
> David/Marco - what do I need to do to make this properly accessible?
> Thanks

First step is to unplug your mouse and make sure you don't get stuck just using the keyboard. Make sure you can invoke the tool, get focus into and out of the tool, and access the tools features. I'm not sure how to get focus to the CL. It should probably be put in the [F6] cycle list.

(Next step is semantics -- probably some role and aria-* attributes)

Comment 5

[Joe Walker [:jwalker]]

So the situation at the moment is that like the current web console, you can TAB into the input element, but you need to use F6 to carry on because we're trapping TAB to mean 'complete'. I'm not sure what to do about that problem.

(On a related note, I've just discovered a TAB problem on the existing web console which has an easy fix, see bug 660864 the completion node has tabindex=-1 in GCLI)

Do you have any recommendations for aria roles? I've spent some time reading up this afternoon, but I'm no expert. We have 2 elements one on top of the other, one being the actual input, the other provides completion help and is positioned behind the actual input (which is transparent)
I'm thinking that the completion node should perhaps be aria-autocomplete, except that it's not a traditional auto-complete node.

Comment 6

[Marco Zehe (:MarcoZ)]

(In reply to comment #5)
> So the situation at the moment is that like the current web console, you can
> TAB into the input element, but you need to use F6 to carry on because we're
> trapping TAB to mean 'complete'. I'm not sure what to do about that problem.

There is no solution other than to document that F6 gets you out of there keyboard-wise. If tab is to be used to autocomplete, which is a common use case, then that's simply it. In ChatZilla it's the same story, and everybody gets along with it.

> (On a related note, I've just discovered a TAB problem on the existing web
> console which has an easy fix, see bug 660864 the completion node has
> tabindex=-1 in GCLI)

There is an older bug on that filed, bug 583816, which also deals with this problem.

> Do you have any recommendations for aria roles? I've spent some time reading
> up this afternoon, but I'm no expert. We have 2 elements one on top of the
> other, one being the actual input, the other provides completion help and is
> positioned behind the actual input (which is transparent)
> I'm thinking that the completion node should perhaps be aria-autocomplete,
> except that it's not a traditional auto-complete node.

A role may not be appropriate/necessary here. If it is not an actual interaction other than auto-complete or selection via up and down, it should announce itself maybe via an aria-live attribute set. Look on the Yahoo! search feature how they do it. If they have suggestions in that popup, they give an announcement via aria-live that something's there, and when the user arrows, they provide the correct selection either via aria-live or via setting the selection, and if it's a custom widget, using something like aria-activedescendant or such.

Comment 7

[Joe Walker [:jwalker]]

(In reply to comment #6)
> (In reply to comment #5)
> > So the situation at the moment is that like the current web console, you can
> > TAB into the input element, but you need to use F6 to carry on because we're
> > trapping TAB to mean 'complete'. I'm not sure what to do about that problem.
> 
> There is no solution other than to document that F6 gets you out of there
> keyboard-wise. If tab is to be used to autocomplete, which is a common use
> case, then that's simply it. In ChatZilla it's the same story, and everybody
> gets along with it.

I've documented the F6 thing, I've also tried having ALT+TAB/CTRL+TAB/META+TAB blur the command line, however that appears to just make nothing focused, and no amount of pressing TAB gets it back. Maybe it's possible to simulate a TAB keypress event? Maybe I'm just clutching at straws!

> > Do you have any recommendations for aria roles? I've spent some time reading
> > up this afternoon, but I'm no expert. We have 2 elements one on top of the
> > other, one being the actual input, the other provides completion help and is
> > positioned behind the actual input (which is transparent)
> > I'm thinking that the completion node should perhaps be aria-autocomplete,
> > except that it's not a traditional auto-complete node.
> 
> A role may not be appropriate/necessary here. If it is not an actual
> interaction other than auto-complete or selection via up and down, it should
> announce itself maybe via an aria-live attribute set. Look on the Yahoo!
> search feature how they do it. If they have suggestions in that popup, they
> give an announcement via aria-live that something's there, and when the user
> arrows, they provide the correct selection either via aria-live or via
> setting the selection, and if it's a custom widget, using something like
> aria-activedescendant or such.

So I've set aria-live="polite" on the completion node, but I'm wondering if the correct setting is assertive rather than polite. The completion text tells you what will happen if you press TAB, there isn't actually a menu yet.

I've set aria-live="assertive" on the command line output on the assumption that it's more important to hear the output of the last command than the completion of the next. This too isn't 100% clear to me.

Advice appreciated!

Finally I've raised bug for part 2 of GCLI where we add in a help menu. See bug 661172.

Comment 8

[Joe Walker [:jwalker]]

Addendum: When embedded into firefox, I think we can do document.commandDispatcher.advanceFocus() rather than blur().

Comment 9

[Joe Walker [:jwalker]]

I'm keen to get this issue squared away.
I've got the tabbing issue fixed, is there anything else you'd recommend?

Comment 10

[Joe Walker [:jwalker]]

I'm going to mark this bug closed. If there are problems we'll file something new, and for the initial release this is going in preffed off anyway.
Thanks.