Re: role mapping rules when context is broken

Hi Alex,

On 2015-10-29 2:08 PM, Alexander Surkov wrote:
> Hi. I don't see whether UAIG addresses the case when role was used in 
> a wrong context [1], for example, if parent of role="gridcell" is not 
> role="row". In this case IAccessibleTableCell interface is not 
> applicable for this gridcell accessible, so should the accessible have 
> GRIDCELL role and should the element be accessible at all?

A few thoughts.

This is the kind of error that checking tools should find.  For example, 
W3C's Nu HTML checker will note the context error.  Here's an example:

However, that said, markup will sometimes have such errors in them. The 
Core-AAM (and the UAIG before it) has a section on author errors [1] 
that mainly says that browsers don't do much in terms of error 
correction.  Specifically, they don't validate "Elements that do not 
correctly observe required child/parent role relationships or that 
appear elsewhere than in their required parent".

A compromise would be to give the accessible a generic role in these 
cases.  That doesn't seem like much work.  Consider that the element 
might fire a focus or other accessibility API  event.  Or, it may have 
an aria-flowto, aria-controls, or other information that would be lost 
if it were simply dropped out of the tree.  I suppose if it has no 
semantic value -- no events, no label, no relationships, etc. -- and has 
a bad role, then it could be dropped from the tree.

There's a similar error regarding abstract roles and their mapping. The 
rule there is that browsers MUST NOT map an abstract role [2, item 2], 
but it doesn't say what to do.  It looks like FF gives uses the 
element's role mapping in that case.  For example, <p role="command"> is 
mapped as ROLE_PARAGRAPH, and <div role="command"> is mapped as 

So:  use the element's role mapping?  Or assign it a generic role?


item 2.


'Array(16).join("wat" - 1) + " Batman!"'
            - G. Bernhardt -

Received on Friday, 30 October 2015 18:32:03 UTC