Re: elements with presentational content

Hi, Joseph. Answering inline.


On Thu, May 29, 2014 at 9:43 AM, Joseph Scheuhammer <clown@alum.mit.edu>
wrote:

> 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.
>

Right. It'd be great however to put it into some nice wording, at least to
add a link to this definition.


> 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.


I see the point. Perhaps ARIA shouldn't be so restrictive, the web looks
too diverse for that. I agree it's different issue though.


 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.
>

It's just one of possible implementations even if the control may be
perceived as two controls by the user.


>
> 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.
>

I'm not sure I've got how the widget will look like. Having an example is
great.

So ARIA can say that button and others are atomic controls and then the
author trying to make something more will fail. If ARIA decides to be not
restrictive then authors will get more freedom in the widgets design. And
then it'd be great if ARIA provided a mechanism to hint the browser about
presentationability of the content.


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