Re: elements with presentational content

Hi Alex,

On 2014-05-29 2:33 PM, Alexander Surkov wrote:
> Hi, Joseph. Answering inline.
>
>
> On Thu, May 29, 2014 at 9:43 AM, Joseph Scheuhammer 
> <clown@alum.mit.edu <mailto: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.

I have added the link, see 
http://rawgit.com/w3c/aria/master/implementation/aria-implementation.html#exclude_elements2

Feel free to open a bug or issue against the spec to request better 
wording for its "Presentational Children" section.  It'd be great if you 
could suggest the proper wording.  You may also want to open another bug 
against the button role requesting that it be modified to allow 
non-presentational children.

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

I'm not sure what you mean by "look like".  How it is rendered depends 
on CSS, and not on ARIA.  ARIA is for semantic structure as exposed in 
a11y APIs.  If you mean how the a11y tree would look, here's a rough 
attempt at an example.  It's based on the assumption that all 
descendants of a button role are presentational unless overridden by the 
author with an explicit non-presentational role.

Given this markup of a non-atomic button:

<div role="button">
   Save
  <!-- Any number of divs and spans purely for layout, borders, 
graphics, and what not.  They have an implied role="presentation" -->
   <div> ... </div>
  <!-- Override the implied presentation with and explicit 
role="checkbox" -->
   <div role="checkbox" aria-checked="false">
     Save only to local drives
   </div>
</div>

The a11y tree would not include any of the divs and spans that have 
role="presentation", but it would include the checkbox that has a role 
override:

- <root>
...
-- button (name: Save)
--- checkbox (name: Save only to local drives, not-checked)
...

For what it's worth, I had a brief chat with the GNOME a11y developers 
this morning.  We discovered that ATK can support a non-atomic button, 
but it was felt that buttons should always be atomic.  A quote from one 
of the participants (name withheld):  "no children of buttons please, 
thank you, i have spoken".  However, I imagine the discussion will continue.

>
> So ARIA can say that button and others are atomic controls and then 
> the author trying to make something more will fail.

Yes, that describes the current state of affairs.

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

Allowing overrides of implicit role="presentation", just as in the case 
of tables and lists, should suffice.

-- 
;;;;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 20:15:49 UTC