Re: elements with presentational content

Hi Alex,

> Hi. Lately I run into examples of widgets having presentational 
> content as part of their implementation and that content is exposed to 
> AT which is unfortunate. For example a custom button
>
> <div role="button">
>   Presentational content
> </div>
>
> UAIG guide suggests [1] to exclude the content from the tree under 
> certain elements aka "Children of objects which have the 
> characteristic "Children Presentational: True":". It's not clear with 
> me what "Children Presentational" is and that's the first issue.

The definition of presentational children is given at 
http://www.w3.org/WAI/PF/aria/roles#childrenArePresentational. The idea 
is that all of the descendant elements of certain roles have an implicit 
role="presentation", relieving the author of having to explicitly add 
that role to all of the elements of the DOM sub-tree.

With respect specifically to the button role, ARIA 1.0 sees a button as 
atomic.  There is no structure within a button in the sense that buttons 
do not have any required descendants. For example, compare the 
characteristics table of button 
(http://www.w3.org/TR/2014/REC-wai-aria-20140320/roles#button) and 
combobox 
(http://www.w3.org/TR/2014/REC-wai-aria-20140320/roles#combobox). The 
latter requires both a textbox and listbox as children.

> The second one the requirement prevents the author to create menu 
> buttons like:
>
> <div role="button">Button
>   <div role="button">menu button</div>
> </div>
>
> (check out XUL example [2]).

I'm not convinced that this is a single button.  There are clearly two 
interactive areas, even though they are rendered as a single entity.  If 
the user clicks one of the areas, it acts like a push button.  If the 
user clicks the second area, it acts like a menu button.  It looks like 
an attempt at a combobox without an editable field -- a "combobutton"?  
However, if this UI pattern is commonplace, then we should consider 
allowing ARIA buttons to have structure within them.

Note that the section in the spec about presentational children does not 
specify explicitly the effect of setting a role on one of the 
descendants.  It implies that is an author error and is to be ignored, 
but it could also work as an override of the implicit presentational 
role. There is precedence for this where role="presentation" is applied 
to containers with required descendants (e.g., table).  There every 
required descendant (e.g, tr, td) inherits the presentation role, i.e. 
role="presentation" is implicit.  But, that can be overridden by adding 
an explicit role . See 
http://www.w3.org/TR/2014/REC-wai-aria-20140320/roles#presentation, 
specifically:

" Explicit roles on a descendant or owned element override the inherited 
role of presentation, and cause the owned element to behave as any other 
element with an explicit role."

I'd prefer overriding implicit role=presentation to adding aria-hidden 
to the mix.

-- 
;;;;joseph.


'A: After all, it isn't rocket science.'
'K: Right. It's merely computer science.'
              - J. D. Klaun -

Received on Thursday, 29 May 2014 13:43:32 UTC