[Bug 10919] Allow role="presentation" to override the default role of any element

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10919

--- Comment #2 from Martin Kliehm <martin.kliehm@namics.com> 2010-10-01 08:53:19 UTC ---
(In reply to comment #1)
> You say that some screen readers don't recognize a role=tab if it's not a
> direct child of a role=tablist.  You then say that role=presentation "deletes"
> an element from the accessibility mapping, allowing the descendent role=tab to
> act like a child of the role=tablist, thus being recognized.
> 
> Is this latter statement what actually happens in the screenreaders previously
> mentioned?  Or is it a statement of what *should* happen in a good
> screenreader?

When an author doesn't state explicitly that an element should be removed from
the accessibility API "DOM" by using role="presentation", the element and it's
default role should remain intact.  I'll ask the NVDA core developer how it is
handled there, but the accessibility API mapping in general is done by the
browser and only accessed, not modified by a screenreader.

So there are screenreaders that recognize tab as a descendent of tablist even
when other elements are between them, and others where tab is only recognized
as an immediate child of tablist.  Authors can force the latter by removing the
elements in between by using role="presentation", which is in accordance with
the ARIA definition when the elements are used for presentational purposes like
applying shadows or background images.

By the way, the W3C validator mandates that tabs need to be immediate child
nodes of tablist, too.  I believe this is an error as it doesn't take the power
of role="presentation" into account.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Received on Friday, 1 October 2010 08:53:23 UTC