- From: Alexander Surkov <surkov.alexander@gmail.com>
- Date: Mon, 2 Jun 2014 13:44:40 -0400
- To: Joseph Scheuhammer <clown@alum.mit.edu>
- Cc: "W3C WAI Protocols & Formats" <public-pfwg@w3.org>
- Message-ID: <CA+epNseuL=rD2ic-b2=KRLXyW5c3Xso3dtaHMJrC31f31mpfwQ@mail.gmail.com>
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