- From: Bryan Garaventa <bryan.garaventa@whatsock.com>
- Date: Wed, 30 May 2012 22:27:43 -0700
- To: <w3c-wai-ig@w3.org>
----- Original Message ----- From: "Bryan Garaventa" <bryan.garaventa@whatsock.com> To: <free-aria@googlegroups.com> Sent: Wednesday, May 30, 2012 10:21 PM Subject: Re: [free-aria] Important differences between ARIA dialog, alertdialog, and role=presentation support > I'm not questioning the complexity or your workmanship. I think you guys > are awesome. > > What concerns me, is that NVDA has implemented an HTML markup requirement > for ARIA support that is not documented in the spec for user agents. > > I understand that the name (label) is announced before the description. > The point is, that without resorting to an HTML hack that only works in > NVDA, developers cannot stop NVDA from automatically announcing a > description. > > You are correct that many dialogs have text. However this is easily dealt > with using ARIA by voluntarily adding the aria-describedby attribute to > the dialog like so. > > <div role="dialog" aria-describedby="myDesc" > > <div id="myDesc"> > Dialog description... > </div> > ... Form ... > </div> > > The ARIA standards exist for this reason, to advise developers how to > properly implement these controls. If a developer is ARIA savvy enough to > add role=dialog to their control, we have to assume they are smart enough > to know and read from the spec that supporting text should also be > referenced in this manner. > > By trying to automatically correct the mistakes of developers who should > know better, we are inadvertently deviating from the spec itself, and > breaking the functionality of ARIA standard compliant widgets. > > For example, both of the samples I attached to the bug are perfectly HTML > and ARIA standard compliant, but they don't work properly. They work fine > for keyboard only users, just not for screen reader users, because of this > issue. > > I guess the best way to explain this is to recall the browser wars of > yore, where we had one hack for IE, one hack for Opera, one hack for > Safari, one hack for Firefox, and in the darkness bound them, in the land > of Mordor where the shadows lie... > > You see what I mean? If NVDA requires an HTML hack that is not supported > anywhere else because it's not documented in the user agent specification, > we're perpetuating the same problem for screen reader support in the > future by introducing inconsistent accessibility. > > > ----- Original Message ----- > From: "James Teh" <jamie@nvaccess.org> > To: <free-aria@googlegroups.com> > Sent: Wednesday, May 30, 2012 4:38 PM > Subject: Re: [free-aria] Important differences between ARIA dialog, > alertdialog, and role=presentation support > > >> Hi. >> >> Just a few clarifications: >> >> On 31/05/2012 9:13 AM, Bryan Garaventa wrote: >>> If neither of the explicit label attributes are included, then the label >>> is derived from the text of the dialog itself. >> NVDA itself only ever uses the label as provided by the browser. >> >>> From what I understand, the role of alertdialog is similar to dialog, >>> except that the content of an alertdialog is parsed and announced >>> automatically. >> It's announced automatically as the description, not the label. This is >> an important distinction. The description does not override the label. >> The label is announced before the role. The description is announced >> afterwards. >> >>> So the current stance from NVDA, is that dialog and alertdialog are >>> handled as the same widget type, and that all content within a widget of >>> role=dialog is announced >> All content isn't announced. However, if aria-describedby isn't present, >> we do use an algorithm which attempts to determine the "text" of the >> dialog. This algorithm isn't perfect (and never will be), but we aim to >> filter out content which wouldn't normally be considered part of the >> dialog text/message. This is exactly what we do for native dialogs. >> >> My argument here is that everywhere else, dialogs are considered to >> potentially have text. The alertdialog case is obvious, but there are >> dialogs that ARIA wouldn't call alertdialogs that also have text. For >> example, consider a properties dialog which shows information that is not >> interactive. This information should be part of the dialog text (which >> means it will be announced to screen reader users automatically when the >> dialog opens). Thus, we treat an ARIA dialog the same as any native >> dialog and try to determine text if there is no explicit description. To >> NVDA, an ARIA dialog is no different to any other dialog (nor should it >> be). We can implement an ARIA specific hack to differentiate, but this >> seems contrary to the goal of ARIA widgets behaving the same as any >> native widget. >> >> Jamie >> >> -- >> James Teh >> Director, NV Access Limited >> Email: jamie@nvaccess.org >> Web site: http://www.nvaccess.org/ >> Phone: +61 7 5667 8372 >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Free ARIA Community" group. >> To post to this group, send email to free-aria@googlegroups.com. >> To unsubscribe from this group, send email to >> free-aria+unsubscribe@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/free-aria?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "Free ARIA Community" group. > To post to this group, send email to free-aria@googlegroups.com. > To unsubscribe from this group, send email to > free-aria+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/free-aria?hl=en. >
Received on Thursday, 31 May 2012 05:28:20 UTC