Re: Handling of landmark roles on native markup

Old wording makes more sense for me.

I should notice that's a not unique case when ARIA spec is changed in
surprising way for me. For example, nowdays Firefox doesn't follow
accessible name computation spec. Sometime ago I filed a bug against
ARIA impl guide arguing that new wording is not really perfect but I
was told that currently computation algorithm is a part of ARIA spec
and the bug was reasonable closed. I was told to file a bug against
ARIA spec but I don't have an access to do that.

ARIA is restricted to external input, many discussions happens on
phone calls which is not friendly to time zones. As Firefox a11y
developer I was never asked or even told about changes. Thus often I
don't have a chance to provide feedback. Sometimes I have a feeling
that Firefox is no longer part of ARIA progress.

Thanks.
Alex.


On Sat, Mar 17, 2012 at 3:24 AM, Aaron Leventhal - Code
<aaronlevbugs@gmail.com> wrote:
> I recently discovered that Firefox and WebKit-based browsers handle
> landmarks differently.
>
> WebKit implements the current ARIA implementation guide at
> http://www.w3.org/TR/wai-aria-implementation/#mapping_role --
> "For the standard role mechanism of the accessibility API, the user
> agent MUST use the first token in the sequence of tokens in the
> role attribute value which matches, on comparison, the name of any
> non-abstract WAI-ARIA role."
>
> Firefox/Gecko implements an older version of the implementation guide
> at  http://www.w3.org/TR/2009/WD-wai-aria-implementation-20090224/#mapping_role
> "The first role token with a known mapping to accessibility APIs SHOULD be
> used when mapping to the accessibility API via the standard role mechanism
> of the accessibility API. Use the role table below and apply any special
> case rules that are specified."
>
> As I see it, there are two advantages to the older system:
> 1. The landmark role can complement native semantics without clobbering
> them, e.g.
>  <input type="text" role="search">
>  <table role="complementary">
>  <ul role="navigation">
> 2. It enables forward compatibility of ARIA-enabled content with future
> browsers and platforms, as fallback roles can be used. For example, <table
> role="calendar grid"> allows newer platforms who understand a "calendar"
> role to map directly to that, but previous versions which did not know about
> "calendar", would fall back on "grid", still a valid, usable role.
>
> I'd like to help sync the browser implementations on this issue. My
> (opinion) is that the older role processing is better for the reasons given
> above. I would love to hear other opinions.
>
> Thanks as always,
> Aaron
>

Received on Tuesday, 20 March 2012 09:37:24 UTC