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

In the Attached file the ARIA-DESCRTBEDB text that is hidden is announced #2597

Closed
nvaccessAuto opened this issue Aug 14, 2012 · 9 comments
Closed

Comments

@nvaccessAuto
Copy link

Reported by rnickelson on 2012-08-14 16:35
In the attached file when TABBING to the edit field in ie or ff NVDA announces the text "note 2" even though it has a style of vissibility:hidden.
The expected result is that "note 2" will not be announced.

@nvaccessAuto
Copy link
Author

Comment 1 by jteh on 2012-08-15 00:34
The text of aria-labelledby/aria-describedby targets should be included even if they are hidden. I can't find the exact section of the spec that notes this, but the User Agent Implementation Guide certainly does in section 5.6.1.3: Text Alternative Computation:

  1. Skip hidden elements unless the author specifies to use them via an aria-labelledby or aria-describedby being used in the current computation.

Note the "unless".
Changes:
Added labels: invalid
State: closed

@nvaccessAuto
Copy link
Author

Attachment test.html added by rnickelson on 2012-08-15 15:24
Description:

@nvaccessAuto
Copy link
Author

Comment 2 by rnickelson on 2012-08-15 15:25
I added ARIA hidden true to the describedby text and it is still announced.

@nvaccessAuto
Copy link
Author

Comment 3 by rnickelson on 2012-08-15 15:30
Changes:
Removed labels: invalid
State: reopened

@nvaccessAuto
Copy link
Author

Comment 4 by benjaminhawkeslewis on 2012-08-15 16:51
NVDA (or the underlying user agent) is still behaving correctly, since the "hidden elements" include elements set hidden using "aria-hidden". The text quoted by jteh refers back to the definition of "hidden" in the spec's glossary:

"An element is only considered hidden in the DOM if it or one of its ancestor elements has the aria-hidden (state) attribute set to true."

http://www.w3.org/WAI/PF/aria-implementation/#def_hidden

People working on these specs are working on how ARIA descriptions and hiddenness interact, so it would be interesting to know more about your use-case here, i.e. what are you trying to achieve? Why are you specifying an element as part of the ARIA description that you do not want to be included in the description?

@nvaccessAuto
Copy link
Author

Comment 5 by rnickelson on 2012-08-15 18:58
The use case is a field with a tooltip and an error message. The tool tip is always there but of course the error message is not (error message is "note 2" in this case).
I am confused: so if text that is not on screen because of visibility:hidden, and also hidden from screen readers by aria hissen being set to true. Why is the text supposed to be announced if it is hidden two ways. it is my understanding that if the aria hidden attribute is true then screen readers are supposed to ignore that text.

@nvaccessAuto
Copy link
Author

Comment 6 by jteh (in reply to comment 5) on 2012-08-16 01:45
Replying to rnickelson:

The use case is a field with a tooltip and an error message. The tool tip is always there but of course the error message is not (error message is "note 2" in this case).

I think a better way to implement this would be to give the error message a role of alert. This way, screen readers will speak it when it appears. The description isn't a good place for an error message. Among other things, in practical terms, it may not be read by a screen reader when it appears.

I am confused: so if text that is not on screen because of visibility:hidden, and also hidden from screen readers by aria hissen being set to true. Why is the text supposed to be announced if it is hidden two ways. it is my understanding that if the aria hidden attribute is true then screen readers are supposed to ignore that text.

That's true except for label and description. Basically, aria-hidden is just another way to indicate hiddenness; the rules don't differ depending on the "type" of hiddenness.

In any case, this is a spec issue, not an NVDA issue.
Changes:
Added labels: invalid
State: closed

@nvaccessAuto
Copy link
Author

Comment 7 by jonavila on 2012-08-23 12:46
Thank you for looking into this issue based on the following quotes from the user agent implementation Guide:

1.Skip hidden elements unless the author specifies to use them via an aria-labelledby or aria-describedby being used in the current computation. By default, users of assistive technologies won't receive the hidden information, but an author will be able to explicitly override that and include the hidden text alternative as part of the label string sent to the accessibility API.

and

Indicates that the element is not visible or perceivable to any user. An element is only considered hidden in the DOM if it or one of its ancestor elements has the aria-hidden (state) attribute set to true.

This is how I believe the spec was meant to be interpreted:

  1. Element hidden via CSS display:none/visibility:hidden aren't rendered to the screen reader user unless they are referenced by aria-describedby or aria-labelledby in which case they can be used for the name. (I personally disagree with this but ok - for this case that is what the spec says)
  2. If aria-hidden is used - the item is considereed hidden in the DOM. In the example above the labels and descriptions are still announced even when aria-hidden is applied. I believe they should not be because the spec indicates they should NOT be in the DOM.

I know there is a separate bug regarding aria-hidden and NVDA but my read of the spec (and the spec is a little unclear in this area) is that aria-hidden is the key to exposing or not exposing this information.

Regarding the purpose for this situation. Some fields can have multiple content associated with them, a label, tooltips, and error messages. What we are finding that people do is have these multiple labels hidden with display:none but when certain things occur such as the need for a tooltip or the need for an error the CSS is changed and the label is then displayed. Now obviously this could be done by adding and deleting DOM nodes or by changing the inner text/text content of a node. But that theoretically shouldn't be needed.

Using ARIA alert on the error messages is not sufficient as that will announce the messages when the appear but not when show them with the field labels when the user tabs from field to field (which is the purpose). Having dynamically changing aria-labels or descriptions is not an unrealistic item. It would appear that something needs to be done either at the spec level or the screen reader level to address questions such as this. There has to be some way to hide content from inclusiion in labels and descriptions and there isn't any method.

wrote

the rules don't differ depending on the "type" of hiddenness.

agent guide says
Hidden: Indicates that the element is not visible or perceivable to any user. An element is only considered hidden in the DOM if it or one of its ancestor elements has the aria-hidden (state) attribute set to true.

My read of user implementation guide indicates that there is a difference between items hidden via CSS and those that are hidden and also have the aria-hidden attribute applied. The key difference I see is that the latter is removed from the DOM while the former is not.

Changes:
Removed labels: invalid
State: reopened

@nvaccessAuto
Copy link
Author

Comment 8 by jteh on 2012-08-23 20:35
The guide says to "Skip hidden elements unless the author specifies to use them via an aria-labelledby or aria-describedby" and aria-hidden="true" satisfies the definition given for "hidden". A separate definition is not given for "hidden in the DOM", so "in the DOM" is just an additional qualifying phrase.

In any case, this is how Mozilla have interpreted the spec (and I concur, as does comment:4). NVDA relies on the labels and descriptions communicated by Firefox. If you disagree, you can file a bug with Mozilla, but I suspect you will see the same response, in which case you'll need to have this clarified by the ARIA spec maintainers.
Changes:
Added labels: invalid
State: closed

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

1 participant