Re: elements with presentational content

Hi, Joseph. I'm not so confident about atomic buttons as gnome developers
but I think I can be convinced this or that way. However I think I saw your
checkbox inside button example in the wild. So I'd rather lean towards to
not being so restrictive for those roles.

Having smart filtering is a good solution, however it may be implementation
cost heavy. But it sill works. I'm curious if some special attribute to
control the subtree (aria-leaf) is still needed. Perhaps it might be useful
in conjunctions with other roles that typically have children.


On Thu, May 29, 2014 at 4:15 PM, Joseph Scheuhammer <clown@alum.mit.edu>
wrote:

> 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 Monday, 2 June 2014 17:45:09 UTC