1001628 - [AccessFu] Improve listbox output verbosity.

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Yura Zenevich [:yzen] (please use "needinfo")]

There are several things that need to be improved:
* link, graphic and button output should exclude their type if the context is application
* note should be included in traversal
* Make the role string a little less verbose for listboxes and listbox options.

Comment 1

[Yura Zenevich [:yzen] (please use "needinfo")]

Attachment: 1001628 patch part 1

Comment 2

[Yura Zenevich [:yzen] (please use "needinfo")]

Attachment: 1001628 patch part 2

Comment 3

[Yura Zenevich [:yzen] (please use "needinfo")]

Attachment: 1001628 patch part 3

Comment 4

[Marco Zehe (:MarcoZ)]

Comment on attachment 8412889 [details] [diff] [review]
1001628 patch part 2

Why do you think the user doesn't want to know that a button is a button or a link is a link from within an application container? If I applied this logic to a desktop screen reader, none of the toolbar buttons inside Google Docs, for example, would read as "button" any more. But this is important information. Note that whatever you change here also affects Firefox for android, so anyone not using Firefox OS, but a web application on their Android device would also be affected by this change in behavior.

Comment 5

[Marco Zehe (:MarcoZ)]

Comment on attachment 8412890 [details] [diff] [review]
1001628 patch part 3

>-listboxoption  =       list box option
>+listboxoption  =       option

Nope, this will need a new ID if I understood our localization people correctly.

Comment 6

[Yura Zenevich [:yzen] (please use "needinfo")]

(In reply to Marco Zehe (:MarcoZ) from comment #5)
> Comment on attachment 8412890 [details] [diff] [review]
> 1001628 patch part 3
> 
> >-listboxoption  =       list box option
> >+listboxoption  =       option
> 
> Nope, this will need a new ID if I understood our localization people
> correctly.

This one is a little tricky since we draw a name directly from a role. As per https://developer.mozilla.org/en-US/docs/Making_String_Changes I don't think the meaning changes so I'm hoping changing the key is not necessary.

Comment 7

[Yura Zenevich [:yzen] (please use "needinfo")]

(In reply to Marco Zehe (:MarcoZ) from comment #4)
> Comment on attachment 8412889 [details] [diff] [review]
> 1001628 patch part 2
> 
> Why do you think the user doesn't want to know that a button is a button or
> a link is a link from within an application container? If I applied this
> logic to a desktop screen reader, none of the toolbar buttons inside Google
> Docs, for example, would read as "button" any more. But this is important
> information. Note that whatever you change here also affects Firefox for
> android, so anyone not using Firefox OS, but a web application on their
> Android device would also be affected by this change in behavior.

Eitan and I were chatting a bit about these controls in the app context and I think we both agreed that there's really no significant distinction between the links and buttons. 

Also I am planning on opening another bug that would enable instruction announcements after a certain interval of inactivity. Announcements such as "Double tap to activate", etc.

I think the role of the control isn't always announced on other platforms (Android at least) either. Perhaps we can determine the verbosity criteria to be more specific than just being the in app context. (marking Eitan for needinfo? here)

Comment 8

[Eitan Isaacson [:eeejay]]

Comment on attachment 8412890 [details] [diff] [review]
1001628 patch part 3

Review of attachment 8412890 [details] [diff] [review]:
-----------------------------------------------------------------

From all three patches, this is the only one I feel 100% certain is good.

Comment 9

[Eitan Isaacson [:eeejay]]

(In reply to Yura Zenevich [:yzen] from comment #7)
> (In reply to Marco Zehe (:MarcoZ) from comment #4)
> > Comment on attachment 8412889 [details] [diff] [review]
> > 1001628 patch part 2
> > 
> > Why do you think the user doesn't want to know that a button is a button or
> > a link is a link from within an application container? If I applied this
> > logic to a desktop screen reader, none of the toolbar buttons inside Google
> > Docs, for example, would read as "button" any more. But this is important
> > information. Note that whatever you change here also affects Firefox for
> > android, so anyone not using Firefox OS, but a web application on their
> > Android device would also be affected by this change in behavior.
> 
> Eitan and I were chatting a bit about these controls in the app context and
> I think we both agreed that there's really no significant distinction
> between the links and buttons. 
> 
> Also I am planning on opening another bug that would enable instruction
> announcements after a certain interval of inactivity. Announcements such as
> "Double tap to activate", etc.
> 
> I think the role of the control isn't always announced on other platforms
> (Android at least) either. Perhaps we can determine the verbosity criteria
> to be more specific than just being the in app context. (marking Eitan for
> needinfo? here)

This is tough! I think iOS does not provide role information for some actionable items such as homescreen icons. But it does of other things, like buttons in apps. Android is still a mess, so I wouldn't take queue from them.

I am fine with the homescreen icons being links.

As for the status bar case, Yura and I discussed this. I think a new role is in need.. Yura suggested the bar have a role of "status", and its children would have a new role called "status item".

Another option is to give the bar a role of "status", and it would have a single child of "list" or "group", where each list item is another thing in the status bar.

Comment 10

[Eitan Isaacson [:eeejay]]

Comment on attachment 8412888 [details] [diff] [review]
1001628 patch part 1

Review of attachment 8412888 [details] [diff] [review]:
-----------------------------------------------------------------

As I said above, using NOTE as a role in the status bar is probably not a good idea. Also, its appropriate use in a document should allow traversal into it and not IGNORE_SUBTREE. So lets not do this!

Comment 11

[Eitan Isaacson [:eeejay]]

Comment on attachment 8412889 [details] [diff] [review]
1001628 patch part 2

Review of attachment 8412889 [details] [diff] [review]:
-----------------------------------------------------------------

As Marco said (and we agreed on IRC), this is probably not a great route. Sorry for suggesting it!

::: accessible/src/jsat/OutputGenerator.jsm
@@ +450,5 @@
>   * An utterance is an array of strings.
>   *
>   * It should not be assumed that flattening an utterance array would create a
>   * gramatically correct sentence. For example, {@link genForObject} might
> + * return: ['entry', 'Welcome to my home page'].

Whats up with this?

Comment 12

[Yura Zenevich [:yzen] (please use "needinfo")]

CC'ing Francesco here since we are changing the properties file without changing the key (similar to bug 908055). 

We want to make the 'list box option' string less verbose since it is repeated for every option item within the list box.

Comment 13

[Yura Zenevich [:yzen] (please use "needinfo")]

https://hg.mozilla.org/integration/mozilla-inbound/rev/80a886fea17d

Comment 14

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/80a886fea17d