Re: Why does the button role have children presentational="true"?

As Bryan mentioned, the processing implications of childrenPresentational and role=presentation are not the same. 

The face that link and button are treated differently is because rendering engines and assistive technologies treat them differently. Feel free to suggest a specific edit (or Pull Request) if you have an idea for improvement.


> On Jan 3, 2016, at 8:47 PM, Birkir Gunnarsson <birkir.gunnarsson@deque.com> wrote:
> 
> The ARIA spec text for most of these widgets (checkbox and link for
> instance)does not state that their descendants are presentational,
> though the same logic should apply to links and buttons (except that
> non-interactive block elements are allowed inside links in html5).
> The spec looks inconsistent to me in this regard.
> 
> 
> On 1/3/16, Bryan Garaventa <bryan.garaventa@ssbbartgroup.com> wrote:
>> I understand the logic of this spec text, but I think it may be misleading
>> to state that role=presentation is implicitly applied to all embedded tags.
>> For example, if this were true, then all instances of aria-label that would
>> otherwise be applied within the naming calculation would be cancelled out,
>> because an element that has been nullified cannot have a name.
>> 
>> I think what is meant by this spec text is that embedded control types
>> within role=button are not allowed, which would be like applying
>> role=presentation on these elements to cancel their native roles out.
>> 
>> E.G a button cannot include embedded links, textboxes, buttons, listboxes,
>> menus, tablists, etc.
>> 
>> Personally I see the same logic applying to quite a few of the other
>> interactive widget roles as well, such as link, checkbox, radio, slider,
>> option, tab, and so on. Basically all of the interactive widget roles that
>> are not composite widgets.
>> 
>> I agree the spec text doesn't really spell this out very well.
>> 
>> 
>> 
>> -----Original Message-----
>> From: Birkir Gunnarsson [mailto:birkir.gunnarsson@deque.com]
>> Sent: Sunday, January 03, 2016 5:50 PM
>> To: Steve Faulkner <faulkner.steve@gmail.com>
>> Cc: ARIA Working Group <public-aria@w3.org>
>> Subject: Re: Why does the button role have children presentational="true"?
>> 
>> Greetings all
>> Thanks Steve for your explanation.
>> So "children presentational" is the equivalent of putting
>> role="presentation" on elements inside the widgets?
>> I find the text from the spec definition of children presentational
>> confusing.
>> "The DOM descendants are presentational. User agents SHOULD NOT expose
>> descendants of this element through the platform accessibility API."
>> My understanding of this paragraph is that the descendants (including their
>> contents) should be hidden from assistive technologies.
>> 
>> I would like to change the wording of this definition in the ARIA 1.1 spec
>> to explain that the semantics of the descendant element should be hidden,
>> the equivalent of putting role="presentation" or "none" on the descendant
>> elements. However, their content should be exposed to assistive technologies
>> according to the accessible name algorithm.
>> 
>> Thanks
>> 
>> 
>> On 12/31/15, Steve Faulkner <faulkner.steve@gmail.com> wrote:
>>> On 31 December 2015 at 15:05, Birkir Gunnarsson
>>> <birkir.gunnarsson@deque.com
>>>> wrote:
>>> 
>>>> <span role="button">New Year's Greetings to <span
>>>> class="IcelandFlag">Iceland</span>
>>>> </span>
>>>> 
>>> 
>>> 
>>> Hi Birkir, role=presentation does not hide text nodes, it only hides
>>> the role semantics (not content) of the element it is on, and any
>>> required children
>>> 
>>> So your example would be same as native button:
>>> 
>>> "New Year's Greetings to Iceland"
>>> 
>>> 
>>> this info may be helpful:
>>> http://w3c.github.io/aria-in-html/#presentation
>>> --
>>> 
>>> Regards
>>> 
>>> SteveF
>>> Current Standards Work @W3C
>>> <http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w
>>> 3c/>
>>> 
>> 
>> 
>

Received on Monday, 4 January 2016 16:43:57 UTC