Spec text indicates aria-hidden is not optional (Re: 48-Hour Call for Consensus (CfC); Publish 1 ARIA FPWD & 2 ARIA Heartbeats)

I've always thought that text was problematic. IIRC, it was for FireFox/ChromeVox. Since FireVox is no more and ChromeVox no longer requires that authoring practice, maybe we can remove the note entirely. Any objections Dominic?

James


> On Dec 3, 2014, at 11:53 AM, Birkir Gunnarsson <birkir.gunnarsson@deque.com> wrote:
> 
> There is an additional problem related to the text and aria-hidden
> attribute.
> The text that Bryan quoted (problematic section of text marked with
> asterisks(:
> "If an element is only visible after some user action, authors MUST set the
> aria-hidden attribute to true. When the element is presented, *authors MUST
> set the aria-hidden attribute to false or remove the attribute, *
> indicating that the element is visible. Some assistive technologies access
> WAI-ARIA information directly through the DOM and not through platform
> accessibility supported by the browser. Authors MUST set aria-hidden ="true"
> on content that is not displayed, regardless of the mechanism used to hide
> it. This allows assistive technologies or user agents to properly skip
> hidden elements in the document."
> 
> This text equates setting aria-hidden to false with removing the aria-hidden
> attribute.
> As indicated in recent discussions, it appears the new intent is that
> aria-hidden="false" overrides any CSS attribute, such as display: none, or
> type="hidden" for <input> elements.
> <div style="display: none;" aria-hidden="false"
> <input type="hidden" value="Default value">
> </div>
> 
> This is already causing confusion with Voiceover 8.1 testing where a lot of
> <input type="hidden"> fields are popping up inside containers with
> aria-hidden="false".

That's an unrelated bug in WebKit. aria-hidden="false" on an ancestor should not affect the display values of child elements.

> If aria-hidden attribute is removed altogether, those would indisputably
> remain hidden.
> 
> So this text definitely needs to be addressed.
> As a larger, and separate, problem, I think aria-hidden="false" should not
> override CSS display settings.

I think you're still conflating a couple UA bugs with the intention of the spec, but I will hold the rest of my thoughts on that until you raise the other thread. FWIW, some of the issues you mentioned are already resolved in the WebKit nightly builds.

> If there is an absolute need for content to
> remain visible to assistive technologies whilst being removed with CSS,
> there should be a more explicit attribute for aria-hidden, such as
> aria-hidden="visible".
> But I will post that as a separate thread.
> Thanks
> -Birkir
> P.S. I still support the CFC, provided that the details will be fixed in
> subsequent drafts, Rome was not built in a day, neither was Florence, South
> Carolina.
> 
> 
> 
> -----Original Message-----
> From: Bryan Garaventa [mailto:bryan.garaventa@ssbbartgroup.com] 
> Sent: Wednesday, December 3, 2014 2:37 PM
> To: Bryan Garaventa; janina@rednote.net; W3C WAI Protocols & Formats
> Subject: RE: 48-Hour Call for Consensus (CfC); Publish 1 ARIA FPWD & 2 ARIA
> Heartbeats
> 
> Also, the statement
> 
> "If an element is only visible after some user action, authors MUST set the
> aria-hidden attribute to true."
> 
> This looks like the spec text is saying that you should put
> aria-hidden='true' on visually displayed elements?
> 
> -----Original Message-----
> From: Bryan Garaventa [mailto:bryan.garaventa@ssbbartgroup.com] 
> Sent: Wednesday, December 03, 2014 11:28 AM
> To: janina@rednote.net; W3C WAI Protocols & Formats
> Subject: RE: 48-Hour Call for Consensus (CfC); Publish 1 ARIA FPWD & 2 ARIA
> Heartbeats
> 
> There appears to be a conflict regarding the aria-hidden attribute spec text
> and what is actually recommended for its use.
> 
> E.G at
> https://rawgit.com/w3c/aria/eaf032dc62e0dc3c25b76db0f2300f972eff6977/aria/ar
> ia.html#terms
> 
> Under Terms > Hidden, it states the following in a note:
> 
> "Note: Authors are reminded that visibility:hidden and display:none apply to
> all CSS media types ; therefore, use of either will hide the content from
> assistive technologies that access the DOM through a rendering engine.
> However, in order to support assistive technologies that access the DOM
> directly, or other authoring techniques to visibly hide content (for
> example, opacity or off-screen positioning), authors need to ensure the
> aria-hidden attribute is always updated accordingly when an element is shown
> or hidden, unless the intent of using off-screen positioning is to make the
> content visible only to screen reader users and not others."
> 
> This makes sense, since it would ensure that aria-hidden is not needed on
> elements that already include display:none, but would be included within
> offscreen layers such as within carousels so that only the currently visible
> slide is shown at one time. It also provides instruction for when offscreen
> text should not include aria-hidden in order to provide screen reader
> accessible information when needed.
> 
> However, within the spec text at
> https://rawgit.com/w3c/aria/eaf032dc62e0dc3c25b76db0f2300f972eff6977/aria/ar
> ia.html#aria-hidden
> 
> It states the following:
> 
> "If an element is only visible after some user action, authors MUST set the
> aria-hidden attribute to true. When the element is presented, authors MUST
> set the aria-hidden attribute to false or remove the attribute, indicating
> that the element is visible. Some assistive technologies access WAI-ARIA
> information directly through the DOM and not through platform accessibility
> supported by the browser. Authors MUST set aria-hidden ="true" on content
> that is not displayed, regardless of the mechanism used to hide it. This
> allows assistive technologies or user agents to properly skip hidden
> elements in the document."
> 
> The spec text directly contradicts the guidance in the note, by saying that
> all hidden content, offscreen or otherwise, must include aria-hidden='true'.
> 
> -----Original Message-----
> From: janina@rednote.net [mailto:janina@rednote.net] 
> Sent: Wednesday, December 03, 2014 10:37 AM
> To: W3C WAI Protocols & Formats
> Subject: 48-Hour Call for Consensus (CfC); Publish 1 ARIA FPWD & 2 ARIA
> Heartbeats
> 
> Colleagues:
> 
> This is a Call for Consensus (CfC) to the Protocols and Formats Working
> Group to approve publication of the following three ARIA related
> documents:
> 
> *	A First Public Working Draft (FP:WD of the 
> 
> Accessible Name and Description: Computation and API Mappings
> https://rawgit.com/w3c/aria/6cd22e8b0a834c4a54b7c6e4496a5887cc43f7ea/accname
> -aam/accname-aam.html
> 
> *	Updated (heartbeat) drafts of the following 2 documents:
> 
> Core Accessibility API Mappings 1.1
> https://rawgit.com/w3c/aria/edfde333e76d19c4bf7a421978eaf89b7d9701e6/core-aa
> m/core-aam.html
> 
> Accessible Rich Internet Applications (WAI-ARIA) 1.1
> https://rawgit.com/w3c/aria/eaf032dc62e0dc3c25b76db0f2300f972eff6977/aria/ar
> ia.html
> 
> ACTION TO TAKE
> 
> According to our agreed Consensus Procedures, this CfC is now open for
> objection, comment, as well as statements of support via email. Silence will
> be interpreted as support, though messages of support are certainly welcome.
> 
> If you object to this proposed action, or have comments concerning this
> proposal, please respond by replying on list to this message no later than
> 17:00 (5PM) Boston Time on Friday 5 December.
> 
> Janina
> 
> 
> -- 
> 
> Janina Sajka,	Phone:	+1.443.300.2200
> 			sip:janina@asterisk.rednote.net
> 		Email:	janina@rednote.net
> 
> Linux Foundation Fellow
> Executive Chair, Accessibility Workgroup:	http://a11y.org
> 
> The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
> Chair,	Protocols & Formats	http://www.w3.org/wai/pf
> 	Indie UI			http://www.w3.org/WAI/IndieUI/
> 
> -- 
> 
> Janina Sajka,	Phone:	+1.443.300.2200
> 			sip:janina@asterisk.rednote.net
> 		Email:	janina@rednote.net
> 
> Linux Foundation Fellow
> Executive Chair, Accessibility Workgroup:	http://a11y.org
> 
> The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
> Chair,	Protocols & Formats	http://www.w3.org/wai/pf
> 	Indie UI			http://www.w3.org/WAI/IndieUI/
> 
> 
> 
> 
>

Received on Thursday, 4 December 2014 00:27:18 UTC