-
-
Notifications
You must be signed in to change notification settings - Fork 628
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
NVDA doesn't handle role=dialog with supporting ARIA attributes according to spec #2390
Comments
Attachment samples.zip added by bgaraventa on 2012-05-28 02:23 |
Comment 1 by jteh on 2012-05-28 02:28
This says nothing about the contents of the dialog. The reading of the dialog content relates to the description, not the label. As documented for alertdialog:
It's not clear from the spec as to how description should be handled for dialog, but it does refer to alertdialog as being related. Also, dialogs do typically have a caption/description. |
Comment 2 by bgaraventa on 2012-05-28 08:25 "Authors SHOULD provide a dialog label. Labels may be provided with the Regarding naming widgets - ARIA does have a document titled "ARIA User Agent Implementation Guide". This guide has a section titled "Name and Description". Specifically rule 2C " Otherwise, if the attributes checked in rules A and B didn't provide results, text is collected from descendant content if the current The exception to this is the following: "If aria-labelledby and aria-label are both empty or undefined, and if the element is not marked as presentational (role="presentation"), check for the presence of an equivalent host language attribute or element for associating a label, and use those mechanisms to determine a text alternative." So if role=presentation is included on a particular node, that text should not be included within the label calculation. This makes sense, especially if you know there is data that would not make sense as part of a dialog label. There needs to be a way of preventing irrelavent information from being announced. |
Comment 3 by jteh on 2012-05-28 13:00 |
Comment 4 by bgaraventa on 2012-05-28 21:40 I don't know what you mean by description, there isn't anything in the spec that I can find that says a description has to be announced, this is what the label is for. |
Comment 5 by jteh (in reply to comment 4) on 2012-05-28 23:31
To be honest, I don't know of a clean way to enforce "no description". The best I can come up with is pointing aria-describedby at an empty element, but that looks like a big ugly hack to me. We have to fall back to calculating the description if it isn't specified because so many dialogs don't set the description properly (and the spec allows for this).
See the section I quoted above re alertdialog and aria-describedby.
The label is a short "title" for the dialog. The description is the message or caption of the dialog. For example, the title might be "NVDA Update", but the description might be "NVDA 2012.3 is available." |
Comment 6 by bgaraventa on 2012-05-29 16:58 This is actually a really big problem. Take the following scenario for example.
Now, since NVDA ignores role=presentation (which should cause NVDA to ignore all of this content when parsing alternative text according to the user agent specification), and NVDA will announce all of the content regardless what the label is explicitly set to, every country will be announced in addition to the dialog label before it gets around to announcing the currently selected country as expected. Also, since aria-describedby isn't documented in the user agent spec alongside the requirement for aria-label and aria-labelledby, this means that the same ARIA widgets will work differently and with varying accessibility across different Assistive Technologies, which would undermine the whole purpose of standardization. |
Comment 7 by jteh (in reply to comment 6) on 2012-05-29 23:09
As I said, see my quote above from the spec regarding alertdialog.
From the roles spec:
This suggests we should ignore the element, but not its descendants.
First, we don't announce all the content. We try to determine what content would constitute the caption/description of the dialog. This algorithm is necessarily complex and is not perfect, but we've done our best to ensure it only reads labels and text nodes. Second, you're still confusing label and description. Dialogs (even before ARIA) have always had a label and an optional caption/description/message. The presence of a label doesn't necessarily mean there is no caption/description/message. |
Comment 8 by bgaraventa on 2012-05-30 16:53 alertdialog is meant to have its content announced automatically, whereas dialogs are not. There are cases where both are valuable implementations. The problem here is that NVDA is enforcing alertdialog behavior regardless, and ignoring cases when a simple dialog is more accessible. The case for making role=presentation only apply to direct descendants doesn't work in practice, especially when you have other role types in the mix. E.G
Since you can't change the roles of an object without rerendering the object, this is the only way to prevent the list from being included, but if you are only including the first level of descendants, then none of the list items are included in the calculation. This is also true for more complex controls like data tables, ARIA grids, and so on. There has to be a way of roping off content like this programmatically to ensure accessibility. |
Comment 9 by bgaraventa on 2012-05-30 17:19 |
Comment 10 by jteh (in reply to comment 9) on 2012-05-30 22:18
If what you say is true for ARIA (and I'd argue the spec is unclear on this), ARIA is clearly differentiating itself from normal platform dialogs, where there is always the possibility of dialog text. Consider, for example, a properties dialog containing information that is not interactive but still very relevant to the user. It makes sense that we should read this information. NVDA just treats an ARIA dialog the same way it treats any other dialog, which is the whole point of ARIA: to make web widgets "feel" native. (Btw, a dialog and an alertdialog look the same to a screen reader. We have to do very specific interrogation to determine that there is a difference.)
I need to follow this up with others in the ARIA community. If the consensus is that dialogs shouldn't read dialog text, I guess we can implement an ARIA specific change to suppress this behaviour. Replying to bgaraventa:
The roles spec makes no mention of this at all. (One of the problems here is that the roles spec and the UA spec seem to contradict each other on a few points.) In any case, what you're suggesting simply isn't possible without changes to the browser, since role="presentation" elements aren't shown to us at all. |
Comment 11 by jteh (in reply to comment 9) on 2012-05-30 23:46
You noted:
You specifically say dialog label text here, not description text. There is a clear distinction here. Label text is determined by the browser using this algorithm. Btw, the reason that removing role="presentation" stops NVDA from reporting the dialog text in this case is that NVDA's dialog text algorithm doesn't descend into tables. The problem when you add role="presentation" is that the table element isn't seen by NVDA at all, so we have no idea that its content is actually part of a table (which obviously isn't dialog text). |
Comment 12 by jteh on 2012-05-31 07:34 |
Comment 13 by bgaraventa on 2012-06-04 15:47 I understand, this is why aria-label and aria-labelledby are explicitly set in the role=dialog tag, which is to set the label text. I see what you mean about the table not being recognized when role=presentation is not used, and this will be helpful for dialogs of type role=alertdialog. I don't think it will be a problem changing the NVDA functionality to not have standard role=dialog content to not be announced automatically, because the syntax for both behaviors is so simple. E.G If you want a regular dialog where you can explicitly control what content is automatically announced via aria-describedby when it opens and focus is set within, use role=dialog. If you want a dialog that automatically announces dialog content when it opens and focus is set within, use role=alertdialog. This seems perfectly reasonable to me, and it matches the user agent spec exactly. Sometimes it's very important to have explicit control over what is announced to make sure content is intuitive. If you want to ask if others might be impacted by such a change, the ARIA and WebAIM lists might be a good way to do it. I suspect not though, since it's not commonly practiced to use either component type at present until agreement can be reached about the general functionality. |
Comment 14 by bgaraventa on 2012-06-04 15:58 Sorry, that's a double negative and doesn't make sense. I mean it shouldn't be a problem having standard role=dialog components not have their contents automatically announced unless explicitly set, since developers can simply use role=alertdialog for this purpose if they desire it. You get what I mean from the E.G examples. |
Comment 15 by jteh on 2012-08-07 09:02 |
Comment 16 by jteh on 2012-08-08 01:22 |
Reported by bgaraventa on 2012-05-28 02:18
According to the spec at
http://www.w3.org/TR/wai-aria/roles
When role=dialog is used in combination with either aria-label or aria-labelledby within the same attribute, then the contents of the dialog should be ignored when setting focus to an active element within the same dialog.
This does appear to work in some cases, but not in others, which looks like the behavior is inconsistently implemented.
The two attached implementations show this.
The sample with aria-labelledby and role=dialog uses these attributes on a parent tag of a calendar table. Role=presentation is also set on the Table tag, which, also according to spec, should prevent the contents of the table from being parsed for dialog label text when aria-label and aria-labelledby are not included at all.
In this sample however, all of the contents are being announced regardless when focus is set within the dialog using Firefox.
In the second sample, which uses aria-label and role=dialog in the Table tag instead, and does not use role=presentation at all, NVDA does not announce all of the table contents when focus is set within the table after the dialog opens.
This appears to be a fluke however, since, if you activate the Advanced Calendar link, then press the Spacebar on a calendar date to bring up the Edit Comment dialog, NVDA will then announce all of the Edit Comment dialog contents in the same manner as before, regardless that aria-label is included within the same parent tag that contains role=dialog.
So to summarise, both of these implementations should be working identically in NVDA and Firefox, but they both are giving contradictory feedback.
When focus is set within the dialog, none of the dialog contents should be announced. This should be the case for both the calendar dialog, and the Edit Comment dialog. The reason being, that aria-label and aria-labelledby are used in the same tag as role=dialog, so this sets the dialog title.
Also, even if aria-label and aria-labelledby were not included in the first sample, the presence of role=presentation should prevent the contents of the table from being announced in the same manner.
The text was updated successfully, but these errors were encountered: