Re: Handling of landmark roles on native markup

A future ARIA specification may allow for a list of role values, rather
than a single token.

Should that be a consideration in this discussion?

Jon



On 3/22/12 12:02 AM, "Alexander Surkov" <surkov.alexander@gmail.com> wrote:

>> Do we have any estimates of how much deployed content depends on that
>> behavior that couldn't be trivially changed by a few key personnel.
>
>No real estimation. We could search through Gecko, Gecko-based
>application and Firefox add-ons and we could reach developers saying
>"hey, we're going to break accessibility in your application so you
>need to fix it" and one day they will fix it I think. But we can do
>nothing about web.
>
>> Question - when a "ul" is exposed as a navigation landmark only, how
>> are child "li" elements represented to the accessibility tree?
>
>That's a main concern. If I read ARIA spec correctly it make the UA to
>not expose the role and says nothing about other things like hierarchy
>and interfaces. But once we don't have a proper role then all other
>things don't make any sense. Following this I say no accessibles for
>li elements. That's what Firefox does for role="presentation" in case
>of HTML tables for example.
>
>> I guess we're saying that Firefox exposes that node in the
>> accessibility tree as *both* a list and a navigation landmark, whereas
>> the current spec would require it to expose it as a navigation
>> landmark only.
>
>Right. I should notice that the web page following the ARIA spec (<div
>role="search"><table></table></div>) and the web page not following
>ARIA spec (<table role="search"></table>) both work in Firefox. You
>can object that in case of <table role="search"> the author wanted to
>add landmark and remove table semantics and there's nothing about
>keeping things more accessible allowing <table role="search/>. But
>that sounds unfortunate that ARIA spec allows these combos because it
>should be really careful about requiring to remove the native
>semantics since it's easier to reduce accessibility of the web rather
>than help to it.
>
>> Well, I guess one good reason is it seems impossible to speak with
>> consistent language about this: note your emails slips from talking
>> about "special kinds of roles" to "no role".
>
>I think I operated the different terms, "special kinds of roles" meant
>ARIA role, while "no role" meant accessibility API role. Sorry for
>confusion.
>
>Thank you.
>Alex.
>
>
>On Thu, Mar 22, 2012 at 7:14 AM, Benjamin Hawkes-Lewis
><bhawkeslewis@googlemail.com> wrote:
>> On Tue, Mar 20, 2012 at 11:27 AM, Alexander Surkov
>> <surkov.alexander@gmail.com> wrote:
>>> This behavior was
>>> used on the web and in Gecko. For example HTML table@role="main" was
>>> exposed to AT as a landmark table.
>>
>> Do we have any estimates of how much deployed content depends on that
>> behavior that couldn't be trivially changed by a few key personnel.
>>
>> Realistically, only "application", "navigation" and "search" seem
>> likely to be used on elements with specialised semantics rather than
>> "div".
>>
>> The Facebook homepage uses a pattern like:
>>
>>    <form role="search">
>>
>> Since "search" implies a form, I'm not sure any semantics are lost
>> under the newer specced behaviour.
>>
>> I had a grep through the Dojo Toolkit source and was somewhat
>> surprised to see they seem to be making no use of landmarks at all.
>>
>> I also had a grep through WordPress trunk and the only case where this
>> might make a difference would be:
>>
>>    wp-includes/theme-compat/sidebar.php:54:                <ul
>> role="navigation">
>>
>> I guess we're saying that Firefox exposes that node in the
>> accessibility tree as *both* a list and a navigation landmark, whereas
>> the current spec would require it to expose it as a navigation
>> landmark only.
>>
>> Question - when a "ul" is exposed as a navigation landmark only, how
>> are child "li" elements represented to the accessibility tree?
>>
>>> Now new behavior requires us to expose it as a landmark accessible
>>>with no role.
>>
>> [snip]
>>
>>> I don't see a good reason of this.
>>
>> Well, I guess one good reason is it seems impossible to speak with
>> consistent language about this: note your emails slips from talking
>> about "special kinds of roles" to "no role".
>>
>> This sort of ambiguity seems likely to confuse developers new to the
>> @role attribute.
>>
>> --
>> Benjamin Hawkes-Lewis
>

Received on Monday, 26 March 2012 16:44:59 UTC