Speak and Braille aria description in all cases

[feerrenrut]

Link to issue number:

None

Summary of the issue:

Support for simplest aspect of ARIA annotations: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Annotations

Adds support for aria-description which is intended to provide a detailed description of an HTML element, as opposed to the brief label provided by aria-label.

Description of how this pull request fixes the issue:

In Chromium based browsers aria-description is mapped to accDescription.
This PR adds support for reading accDescription in all cases when it is present.

Braille and speech are supported.
Config option Object Pesentation Report Object Descriptions is honored.

Testing performed:

Known issues with pull request:

• This change may result in unwanted higher verbosity, we'll monitor for this and may subsequently adjust the approach taken.
• Attributes such as 'title' (when name is already present eg via 'alt') will be mapped to accDescription, despite the use of title being discouraged, there are still many usages of it.
• Descriptions in braille can be a little confusing, because they are not delineated.

Change log entry:

Changes:

- Descriptions will now be read in all modes, this is to support Aria-annotations.

[michaelDCurran]

Code is fine so far. But We'll want to ensure we present description in braille, and speak descriptionChange event, and think about limiting this feature by checking Object Presentation's reportObjectDescriptions config option.
It is unknown as to how annoying hearing html title attributes all the time after this change. If there is a lot of push back, then I think we'll need to approach Google about specifically aria-description via IAccessible2 attributes and using that rather than accDesciritpion. Note that Firefox currently exposes aria-description this way (though I'm not sure that is entirely deliberate).

[feerrenrut]

I have updated this to handle braille and respect ["presentation"]["reportObjectDescriptions"]. PR description has been updated.

[LeonarddeR]

I had a quick test and I think there's a major thing that should be thought about. When a description on an object is set using aria-describedby, the description can be presented twice, once when it is being read as part of the virtual buffer and once as the description of another element. I believe there's a workaround for this with regard to labels in order for the label not being presented twice.
Also, presenting descriptions like this in braille is a major change, for which it should be considered that it could be enabled for speech only. Especially for long descriptions on an edit field, the experience in braille is somewhat weird. Braille behaves in such a way that the cursor is visible on the display. The start of the line contains the last part of the description.

[LeonarddeR]

It would be very helpful to have an opinion from people like @jcsteh and @MarcoZehe as well.

[feerrenrut]

Thanks for testing @LeonarddeR, your feedback is appreciated. The duplicates shouldn't be too hard to resolve. I have a few ideas which may improve the braille UX:

• Symbols to delimit the description
• Rather than present the description directly use a short abbreviation or symbol to say "has description", using the routing button for that cell will show the description.
• Only show short descriptions

We could use any combination of these ideas if you think it will improve the situation. The final question will be whether we include that UX work in this PR. Getting this PR merged would allow us to work on several different aspects of this in parallel.

[LeonarddeR]

* Rather than present the description directly use a short abbreviation or symbol to say "has description", using the routing button for that cell will show the description.

That makes sense, but it should be limited to documents/browse mode. IN focus mode, the description was always fully visible and that should stay as is IMO.

The final question will be whether we include that UX work in this PR. Getting this PR merged would allow us to work on several different aspects of this in parallel.

I don't think tha'ts necessary, but if not done in this PR, I think this pr should leave braille untouched and introduce the eventual braille ux when it's ready.

[feerrenrut]

Thanks for the notes @LeonarddeR, before going ahead on this I'll give @jcsteh and @MarcoZehe a chance to leave their feedback.

[bramd]

Interesting change. I think we should be careful presenting title attributes by default. I see them used a lot and often it is even just a duplicate of the exact link/button text. Presenting that by default will add a lot of noise. However, now they are almost undiscoverable, because you have to use nvda+tab or nvda+numpad5 to read it and you don't have an indication there is a description.

I think giving an indication that there is a description and providing a gesture to read/braille it would be a better UX. Also, what VoiceOver on Mac does is an interesting approach, speak the description after a configurable delay.

[jcsteh]

The original question related to delineation for braille, but that leaves me with a question: why is this a problem for braille but not speech? In focus mode, the role is spoken between the name and description, so there's delineation. But in browse mode, the role is spoken before the name. So, how is this delineated for speech?

My feeling is probably that we want some indicator for the presence of a description, rather than showing the description. However, I think this is true for speech as well. I'm very concerned about the verbosity here in both cases.

[feerrenrut]

@jcsteh @LeonarddeR @bramd I expected verbosity and delineation to be issues, but to gather the extent to which they cause problems my initial plan was to get feedback from alpha users once this is merged. Essentially giving us evidence for how to prioritize the UX aspect of this work.

While I've got you thinking about this, could you please comment on the following improvement to the UX for both voice and braille:

• Use a symbol / earcon or phrase to indicate "has description"
• A gesture or routing to report / expand the description

There are some cases where description is spoken / brailled currently, I'd be looking at having a consistent user experience so the behavior of these cases would change. Are there cases you know of where it is important NOT to have this level of indirection?

[zstanecic]

Hi to all, My point of view is that verbosity of the aria should be configurable, because there are some newspaper sites which expose ads with these mechanisms. I.e developers use aria to do bad things.

[LeonarddeR]

While I've got you thinking about this, could you please comment on the following improvement to the UX for both voice and braille:

* Use a symbol / earcon or phrase to indicate "has description"

* A gesture or routing to report / expand the description

Makes sense to me

There are some cases where description is spoken / brailled currently, I'd be looking at having a consistent user experience so the behavior of these cases would change. Are there cases you know of where it is important NOT to have this level of indirection?

I think it is helpful most of the time that descriptions are spoken in focus mode, they're there for a reason, and especially when using tab based navigation on forms, any description (e.g. the legend on a form) can be pretty relevant.

I think it is fair to distinguish between browse mode and focus mode in this case.

1. In focus mode, speak descriptions by default. I can't think of a reason why I only want to hear that there is a description, requiring an extra key press to read it. As the description is usually the last part of an object's presentation, I can easily silence it if it's to much.
2. In browse mode, default to a sentence like "has description". Optionally allow people to turn this off entirely or speak the description, but ensure that browse mode doesn't present duplicate content for visible descriptions.

[michaelDCurran]

What about for moving with the caret in focus mode in contentEditables though? Which is really the original reason for this change (I.e. aria-description used within something like Google Docs).

[LeonarddeR]

Ugh, I should have generalized my previous post. instead of browse mode, I actually intended to mean editable content, either in focus or browse mode So in more technical term, either object presentation or control field presentation, respectively,

[michaelDCurran]

So just to double check I understand you fully, when editing a document in Google docs for example, you'd want to hear "has description" or something rather than the actual description when moving with the caret?

[LeonarddeR]

Yes, that's correct. I can think of cases where you want to hear the full description, but that should certainly be optional. The problem is that we don't have control on how description is used. As @bramd pointed out, the html title attribute is mapped to description as well, whereas @zstanecic also has a valid concern.

Note that I"m also not perfectly happy with how aria-description is used in the ariaDescriptionSample in the system tests. it feels to me that these messages are more suited for live regions or alerts than for annotations on the text area.

[jcsteh]

I tend to think description should be reported fully when moving the caret by character or word (extraDetail True), but not line or larger (extraDetail False).

[LeonarddeR]

I tend to think description should be reported fully when moving the caret by character or word (extraDetail True), but not line or larger (extraDetail False).

Hadn't thought about that, marvellous idea

[feerrenrut]

Won't these suggestions incur the same difficulty differentiating description from the main content?

[feerrenrut]

We are going to take another approach to this. I'm closing this PR.

[feerrenrut]

New approach: #12500