Re: Handling of landmark roles on native markup

> 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 Thursday, 22 March 2012 05:03:08 UTC