Re: [free-aria] Important differences between ARIA dialog, alertdialog, and role=presentation support

That sounds good to me as well. If we can reach a consensus about how to 
implement descriptive overrides for occasions that need it, this will help 
everyone.

This is why I suggested the use of role=presentation as a way of roping off 
content that is unsuitable to be included in such an automated description. 
I know the arguments about the purpose of role=presentation, but they too 
aren't clearly defined.

One problem I see with trying to automatically compensate for what 
developers fail to do properly, is that it will encourage lazy coding in the 
future.

So if others have suggestions for a solution to this, please speak up.

----- Original Message ----- 
From: "James Teh" <jamie@nvaccess.org>
To: <free-aria@googlegroups.com>
Sent: Thursday, May 31, 2012 12:27 AM
Subject: Re: [free-aria] Important differences between ARIA dialog, 
alertdialog, and role=presentation support


> On 31/05/2012 3:21 PM, Bryan Garaventa wrote:
>> 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.
> Sure. I do recognise and understand your concern. The work around I 
> suggested is clearly very ugly. However:
>
>> 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.
> The fundamental problem for us is that an ARIA dialog is no different to 
> any other dialog, and for all dialogs, we derive text if it is not 
> explicitly supplied. As I said, if consensus is that this behaviour is 
> incorrect, we can try to implement an exception specifically for ARIA, but 
> this starts to suggest that ARIA widgets should be treated differently 
> from native widgets, which smells ugly to me. We'll have to implement this 
> exception separately for each browser as well.
>
> All of this said, the cards are all on the table now. I am keen to hear 
> others' opinions so we can work towards an acceptable solution.
>
> Jamie
>
> -- 
> James Teh
> Director, NV Access Limited
> Email: jamie@nvaccess.org
> Web site: http://www.nvaccess.org/
> Phone: +61 7 5667 8372
>
>

----- Original Message ----- 
From: "Bryan Garaventa"
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
>>
>>

Received on Thursday, 31 May 2012 18:15:52 UTC