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

Render aria-label in browse mode when it is used to override content #1354

Closed
nvaccessAuto opened this issue Feb 4, 2011 · 22 comments
Closed

Comments

@nvaccessAuto
Copy link

Reported by courtney.christensen@... on 2011-02-04 21:19
The aria-label attribute is currently not recognized on structural HTML elements such as <div> and <span> elements. There are many cases in which this would be valuable. For example, MathJax transcribes MathML alttext into a <span> element with an aria-label:

<span class="MathJax" role="textbox" aria-readonly="true" aria-label=" x equals 0.25">
  <!-- math display code here -->
</span> 

Presently, NVDA ignores the aria-label and speaks the contents as text.

I propose the alternate text be announced "inline", much in the way landmarks are announced. If the child content is not relevant to the screen-reader, it is up to the content author to prevent it from being spoken (though aria-hidden or a similar mechanism).
Blocking #1195, #1362, #3551, #3852, #3889

@nvaccessAuto
Copy link
Author

Comment 1 by jteh on 2011-02-04 21:26
The issue here is that labels are not rendered into virtual buffers because generally, the label is part of the content and we don't want duplicate text. However, in the case of aria-label, the label is inherently not included in the content. We need to differentiate between these cases somehow. In Firefox, this is tricky because we don't know whether a name came from aria-label or something else, although we might be able to use relations to figure this out.

@nvaccessAuto
Copy link
Author

Comment 2 by aleksey_s (in reply to comment description) on 2011-02-04 21:35
Replying to courtney.christensen@…:

I propose the alternate text be announced "inline", much in the way landmarks are announced. If the child content is not relevant to the screen-reader, it is up to the content author to prevent it from being spoken (though aria-hidden or a similar mechanism).

I am not sure that announcing label inline is convenient, esp. for mathematical expressions user might want to navigate it character by character or similarly. So it should be rendered in to buffer as a text.

@nvaccessAuto
Copy link
Author

Comment 3 by courtney.christensen@... (in reply to comment 2) on 2011-02-04 21:42
Replying to aleksey_s:

I am not sure that announcing label inline is convenient, esp. for mathematical expressions user might want to navigate it character by character or similarly. So it should be rendered in to buffer as a text.

That's an ''excellent'' point. In fact, that's one of the bigger accessibility issues we deal with when it comes to math expressions. Descriptions of math equations can quickly become very long and difficult to visualize. Please forgive my ignorance in the way this text is structured in memory -- you're spot on.

@nvaccessAuto
Copy link
Author

Comment 4 by aleksey_s on 2011-02-04 21:54
Interestingly, that NVDA behaves correctly with your example in IE8: It renders " x equals 0.25" into buffer as a text node.

@nvaccessAuto
Copy link
Author

Comment 5 by courtney.christensen@... (in reply to comment 4) on 2011-02-04 22:12
Replying to aleksey_s:

Interestingly, that NVDA behaves correctly with your example in IE8: It renders " x equals 0.25" into buffer as a text node.

Well I'll be...it sure does! However, it doesn't as soon as I add a text child. The following (stupid example) reads "x equals zero point two five" (IE ''only''):

<span aria-label=" x equals 0.25">
  <div><span><input type="checkbox" /></span></div>
</span>

Yet this does not:

<span aria-label=" x equals 0.25">test</span> 

This actually seems like intentional behavior on the part of NVDA, but I have only a cursory knowledge of NVDA. It should be noted that neither example speaks the label in Firefox (4.0b10) or Chrome (9.0.597.84). Not sure if I'm helping here...

@nvaccessAuto
Copy link
Author

Comment 6 by jteh on 2011-07-07 10:13
I filed MozillaBug:637578, as we need some way of determining how the accessible name was determined to know whether to render it as content.
Changes:
Milestone changed from None to near-term

@nvaccessAuto
Copy link
Author

Comment 7 by jteh on 2012-06-20 03:19
Changes:
Changed title from "Support 'aria-label' on

and tags" to "Render aria-label in browse mode when it is used to override content"

@nvaccessAuto
Copy link
Author

Comment 9 by parham on 2012-06-20 04:45
If it helps, in the internal web application our company is creating, I added an aria-label to a span and when I route the mouse with the NVDA+numpadSlash key, the aria-label gets read.

@nvaccessAuto
Copy link
Author

Comment 10 by jteh on 2012-08-31 06:08
This is now partially fixed as of 035874c. If an element produces no visible content, its name will be used. So, if you do <span aria-label="label"><span aria-hidden="true">content</span></span>, NVDA will render "label". However, if you don't use aria-hidden on the inner span, NVDA will render "content".

@nvaccessAuto
Copy link
Author

Comment 11 by jteh on 2012-10-19 01:15
MozillaBug:637578 has been fixed in Firefox 19, so it's now possible for us to eventually handle this better in Firefox. There are still a lot of awkward edge cases, though, so implementing support for this isn't trivial.

@nvaccessAuto
Copy link
Author

Comment 12 by jteh on 2013-03-20 02:12
Changes:
Milestone changed from near-term to 2013.2

@nvaccessAuto
Copy link
Author

Comment 13 by jteh on 2013-04-24 01:48
I was about to implement this, until I realised there's a major flaw. If we do this and someone decides to label a div containing a large chunk of the document, all of that content will be replaced by the label. You could argue that's author error, except people are (misguidedly, in my opinion) using aria-label to label landmarks, etc. This cannot be implemented if there are no clear rules, as it could break many pages.

@nvaccessAuto
Copy link
Author

Comment 14 by jteh on 2013-06-26 02:55
Changes:
Milestone changed from 2013.2 to near-term

@nvaccessAuto
Copy link
Author

Comment 15 by parham (in reply to comment 13) on 2013-10-07 09:57
Replying to jteh:

If we do this and someone decides to label a div containing a large chunk of the document, all of that content will be replaced by the label.

I'm not sure about the proper channels for doing this, but is it possible for the author to explicitly say that the label overrides the content?

Look at the below code as an example. The character between the opening and closing "a" tag is a UTF-8 icon that doesn't make sense to eSpeak (and when eSpeak doesn't read it, I'm not sure if anything would, lol):

<a href="#" aria-label="Settings"></a>

This would definitely need the "Settings" aria label to make sense, although the content inside is... well, something.

@nvaccessAuto
Copy link
Author

Comment 16 by jteh (in reply to comment 15) on 2013-10-07 16:35
Replying to parham:

I'm not sure about the proper channels for doing this, but is it possible for the author to explicitly say that the label overrides the content?

Not at present; that's the problem here.

Look at the below code as an example.

<a href="#" aria-label="Settings"></a>

That character is in the Unicode private use area. There was some talk of overriding content with the label for such characters, which might solve this case.

Btw, while I generally oppose aria-hidden, here's a possible work around for this case:

<a href="#" aria-label="Settings"><span aria-hidden="true"></span></a>

@nvaccessAuto
Copy link
Author

Comment 17 by jteh on 2013-11-27 06:21
There doesn't seem to be a clear, safe way to implement this. I proposed a work around in comment:16. Also, we're going to investigate special handling for private use Unicode characters (#2963).
Changes:
Added labels: wontfix
State: closed

@nvaccessAuto
Copy link
Author

Comment 18 by jteh on 2014-02-14 08:54
I'm going to try to implement this. Note that there's no clear specification as to correct behaviour, so we'll just have to make our own decisions about the best way to handle this.

Aria-label(ledby) still won't override the content for spans and divs because this would break labelled landmarks, regions, etc.
Changes:
Removed labels: wontfix
State: reopened

@nvaccessAuto
Copy link
Author

Comment 19 by jteh on 2014-02-14 08:55
Changes:
Milestone changed from near-term to next

@nvaccessAuto
Copy link
Author

Comment 21 by MarcoZehe on 2014-02-15 05:40
Glad to see this moving forward! I also looked at the two commits for this ticket and think it's a good approach. Let me know if you need any feedback or testing!

@nvaccessAuto
Copy link
Author

Comment 23 by James Teh <jamie@... on 2014-02-17 03:41
In [49fa402]:

Merge branch 't1354' into next

Incubates #1354.

Changes:
Added labels: incubating

@nvaccessAuto
Copy link
Author

Comment 25 by James Teh <jamie@... on 2014-03-10 04:54
In [bd8aed6]:

In browse mode, the labels of controls such as links and buttons are now rendered correctly where the label has been overridden by the author for accessibility purposes (specifically, using aria-label or aria-labelledby).

Fixes #1354.

Changes:
Removed labels: incubating
State: closed

@nvaccessAuto
Copy link
Author

Comment 26 by jteh on 2014-03-10 04:56
Changes:
Milestone changed from next to 2014.2

devtools-bot pushed a commit to ChromeDevTools/devtools-frontend that referenced this issue Oct 17, 2019
Without this change screen readers in browse mode [1] will incorrectly
read errors and warnings that have a tooltip of "42 errors, 99 warnings"
as "4299".

After this change screen readers will announce the same content as the
shown in the tooltip: "42 errors, 99 warnings".

Because errors and warnings are indicated with icons this change will
fix the screen reader bug and helps meet success criteria for
WCAG 1.1.1 Non-text Content [2].

Root cause:
The icons do not have accessible names and screen readers will combine
the content of the spans:

   <span><error-icon/>42<span><span><warning-icon/>99</span>
   is announced as 4299

The fix:
* Set the accessible name of counter element (title alone is insufficient [3]).
* Make the children of the counter hidden otherwise NVDA (and JAWs)
  screen readers will ignore the aria-label [4].

[1]: https://www.nvaccess.org/files/nvda/documentation/userGuide.html#BrowseMode
[2]: https://www.w3.org/WAI/WCAG21/quickref/#non-text-content
[3]: https://crrev.com/18d41172/third_party/blink/renderer/devtools/front_end/ui/Tooltip.js#190
[4]: nvaccess/nvda#1354 (comment)

Screenshot (NVDA speech viewer): https://i.imgur.com/KznR7O7.png
      screen reader should announce the number of errors and warnings.

Test: Navigate to the counter in NVDA browse mode on Win10 and the
Bug: 963183
Change-Id: I46985e223a6f8bac5cd1dbdf597a4b0c9ab71567
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1861214
Reviewed-by: Lorne Mitchell <lomitch@microsoft.com>
Commit-Queue: John Emau <John.Emau@microsoft.com>
Cr-Original-Commit-Position: refs/heads/master@{#707031}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 5814dabc5bfa705994cea056b539243789e481c9
babot pushed a commit to binaryage/dirac that referenced this issue Oct 18, 2019
Without this change screen readers in browse mode [1] will incorrectly
read errors and warnings that have a tooltip of "42 errors, 99 warnings"
as "4299".

After this change screen readers will announce the same content as the
shown in the tooltip: "42 errors, 99 warnings".

Because errors and warnings are indicated with icons this change will
fix the screen reader bug and helps meet success criteria for
WCAG 1.1.1 Non-text Content [2].

Root cause:
The icons do not have accessible names and screen readers will combine
the content of the spans:

   <span><error-icon/>42<span><span><warning-icon/>99</span>
   is announced as 4299

The fix:
* Set the accessible name of counter element (title alone is insufficient [3]).
* Make the children of the counter hidden otherwise NVDA (and JAWs)
  screen readers will ignore the aria-label [4].

[1]: https://www.nvaccess.org/files/nvda/documentation/userGuide.html#BrowseMode
[2]: https://www.w3.org/WAI/WCAG21/quickref/#non-text-content
[3]: https://crrev.com/18d41172/third_party/blink/renderer/devtools/front_end/ui/Tooltip.js#190
[4]: nvaccess/nvda#1354 (comment)

Screenshot (NVDA speech viewer): https://i.imgur.com/KznR7O7.png
      screen reader should announce the number of errors and warnings.

Test: Navigate to the counter in NVDA browse mode on Win10 and the
Bug: 963183
Change-Id: I46985e223a6f8bac5cd1dbdf597a4b0c9ab71567
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1861214
Reviewed-by: Lorne Mitchell <lomitch@microsoft.com>
Commit-Queue: John Emau <John.Emau@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#707031}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants