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

Actually I think the note is correct, but the spec text is wrong.

For example, it says that visible content must have aria-hidden="true", and all offscreen content must also have aria-hidden="true".

E.G

"If an element is only visible after some user action, authors MUST set the aria-hidden attribute to true."

And 

"Authors MUST set aria-hidden ="true" on content that is not displayed, regardless of the mechanism used to hide it."

If developers follow this exactly, this will cause all dynamically displayed content to be made totally invisible to assistive technology users, and cause all legitimately helpful offscreen content to be made similarly invisible to those same users.

I don't mean to be a pain, but this is the opposite of making dynamic web technologies helpful or accessible.


-----Original Message-----
From: James Craig [mailto:jcraig@apple.com] 
Sent: Wednesday, December 03, 2014 4:27 PM
To: Birkir Gunnarsson; Dominic Mazzoni
Cc: Bryan Garaventa; Janina Sajka; W3C WAI Protocols & Formats
Subject: 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/a
> ria/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/a
> ria/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/a
> ccname
> -aam/accname-aam.html
> 
> *	Updated (heartbeat) drafts of the following 2 documents:
> 
> Core Accessibility API Mappings 1.1
> https://rawgit.com/w3c/aria/edfde333e76d19c4bf7a421978eaf89b7d9701e6/c
> ore-aa
> m/core-aam.html
> 
> Accessible Rich Internet Applications (WAI-ARIA) 1.1 
> https://rawgit.com/w3c/aria/eaf032dc62e0dc3c25b76db0f2300f972eff6977/a
> ria/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 04:12:04 UTC