E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 3 (In chronological order)

From: Bryan Garaventa
Date: Thu, May 31 2012 12:15PM
Subject: [free-aria] Important differences between ARIA dialog, alertdialog, and role=presentation support
No previous message | Next message →

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" < = EMAIL ADDRESS REMOVED = >
To: < = EMAIL ADDRESS REMOVED = >
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: = EMAIL ADDRESS REMOVED =
> Web site: http://www.nvaccess.org/
> Phone: +61 7 5667 8372
>
>

----- Original Message -----
From: "Bryan Garaventa"
To: < = EMAIL ADDRESS REMOVED = >
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" < = EMAIL ADDRESS REMOVED = >
> To: < = EMAIL ADDRESS REMOVED = >
> 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: = EMAIL ADDRESS REMOVED =
>> Web site: http://www.nvaccess.org/
>> Phone: +61 7 5667 8372
>>
>>

From: Bryan Garaventa
Date: Thu, May 31 2012 12:47PM
Subject: Re: [free-aria] Important differences between ARIA dialog, alertdialog, and role=presentation support
← Previous message | Next message →

I forgot to mention, this is in regard to the bug at
http://www.nvda-project.org/ticket/2390

----- Original Message -----
From: "Bryan Garaventa" < = EMAIL ADDRESS REMOVED = >
To: < = EMAIL ADDRESS REMOVED = >; < = EMAIL ADDRESS REMOVED = >
Cc: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Thursday, May 31, 2012 11:15 AM
Subject: Re: [WebAIM] [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" < = EMAIL ADDRESS REMOVED = >
> To: < = EMAIL ADDRESS REMOVED = >
> 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: = EMAIL ADDRESS REMOVED =
>> Web site: http://www.nvaccess.org/
>> Phone: +61 7 5667 8372
>>
>>
>
> ----- Original Message -----
> From: "Bryan Garaventa"
> To: < = EMAIL ADDRESS REMOVED = >
> 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" < = EMAIL ADDRESS REMOVED = >
>> To: < = EMAIL ADDRESS REMOVED = >
>> 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: = EMAIL ADDRESS REMOVED =
>>> Web site: http://www.nvaccess.org/
>>> Phone: +61 7 5667 8372
>>>
>>>
>
> > >

From: James Nurthen
Date: Thu, May 31 2012 1:19PM
Subject: Re: [free-aria] Important differences between ARIA dialog, alertdialog, and role=presentation support
← Previous message | No next message

Bryan,
I have raised ISSUE-522 against the spec to clarify that role=presentation
does not act to rope of content from the accessibility APIs.
Regards,
James

On Thu, May 31, 2012 at 11:15 AM, Bryan Garaventa <
= EMAIL ADDRESS REMOVED = > wrote:

> 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" < = EMAIL ADDRESS REMOVED = >
> To: < = EMAIL ADDRESS REMOVED = >
> 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: = EMAIL ADDRESS REMOVED =
>> Web site: http://www.nvaccess.org/
>> Phone: +61 7 5667 8372
>>
>>
>>
> ----- Original Message ----- From: "Bryan Garaventa"
> To: < = EMAIL ADDRESS REMOVED = >
> 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" < = EMAIL ADDRESS REMOVED = >
>> To: < = EMAIL ADDRESS REMOVED = >
>> 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: = EMAIL ADDRESS REMOVED =
>>> 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 = EMAIL ADDRESS REMOVED = .
> To unsubscribe from this group, send email to free-aria+unsubscribe@**
> googlegroups.com < = EMAIL ADDRESS REMOVED = >.
> For more options, visit this group at http://groups.google.com/**
> group/free-aria?hl=en <http://groups.google.com/group/free-aria?hl=en>;.
>
>