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

Thanks, is this still the url at
https://rawgit.com/w3c/aria/eaf032dc62e0dc3c25b76db0f2300f972eff6977/aria/aria.html#aria-hidden ?

I’m not sure if this is the same as the ED version.

From: James Craig [mailto:jcraig@apple.com]
Sent: Tuesday, December 16, 2014 12:56 PM
To: Bryan Garaventa
Cc: Dominic Mazzoni; Birkir Gunnarsson; Janina Sajka; W3C WAI Protocols & Formats
Subject: Re: Spec text indicates aria-hidden is not optional (Re: 48-Hour Call for Consensus (CfC); Publish 1 ARIA FPWD & 2 ARIA Heartbeats)

After group discussion, I updated the ED to remove the legacy ChromeVox requirement.

On Dec 3, 2014, at 10:58 PM, Bryan Garaventa <bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>> wrote:

>Consider the now-common pattern of a sidebar that slides in from the left in mobile apps. When you tap the button that dismisses the sidebar, it doesn't
>disappear immediately, it slides away. Functionally, it's inert while sliding away - but AT can still access it, and it's easy to get confused if you tap
>the button to dismiss it but then navigate back to it while it's closing. That seems like a good case for adding aria-hidden=true on the sidebar as soon
>as you dismiss it.

That makes sense to me, and I’ve made the same suggestion for carousels that slide one panel offscreen while loading another into view at the same time, so aria-hidden is helpful in those circumstances.

What concerns me with the spec text though, is that it is a blanket statement, and doesn’t qualify any circumstance where this would not be the case, such as with skip links for example, or other valid usages. The use of “MUST” sort of negates all of these scenarios.

The first sentence is problematic as well, "If an element is only visible after some user action, authors MUST set the aria-hidden attribute to true.".

This sounds like it’s saying, if you cause dynamic content to appear visually through a user interaction, such as by activating an element and something appears visually, it must include aria-hidden=”true”.




From: Dominic Mazzoni [mailto:dmazzoni@google.com]
Sent: Wednesday, December 03, 2014 10:39 PM
To: Bryan Garaventa
Cc: James Craig; Birkir Gunnarsson; Janina Sajka; W3C WAI Protocols & Formats
Subject: Re: Spec text indicates aria-hidden is not optional (Re: 48-Hour Call for Consensus (CfC); Publish 1 ARIA FPWD & 2 ARIA Heartbeats)

You're right, this part sounds like it relates to FireVox/ChromeVox:

> Some assistive technologies access
> WAI-ARIA information directly through the DOM and not through platform
> accessibility supported by the browser.

However, it doesn't apply anymore. The current stable version of ChromeVox does access the DOM, but it does all of the style calculations to determine if an object is visible and displayed, so there's no need to also set aria-hidden if the style is unambiguous.

So yeah, I'd recommend deleting that text. Whether screen readers exist that access the DOM or not, it's a failure if we expect web authors to jump through hoops to accomodate them.

I think, though, there may be some legitimate advice in there too, unless I'm misunderstanding.

Consider the now-common pattern of a sidebar that slides in from the left in mobile apps. When you tap the button that dismisses the sidebar, it doesn't disappear immediately, it slides away. Functionally, it's inert while sliding away - but AT can still access it, and it's easy to get confused if you tap the button to dismiss it but then navigate back to it while it's closing. That seems like a good case for adding aria-hidden=true on the sidebar as soon as you dismiss it.

- Dominic




On Wed, Dec 3, 2014 at 8:11 PM, Bryan Garaventa <bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>> wrote:
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<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<mailto: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<mailto:bryan.garaventa@ssbbartgroup.com>]
> Sent: Wednesday, December 3, 2014 2:37 PM
> To: Bryan Garaventa; janina@rednote.net<mailto: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<mailto:bryan.garaventa@ssbbartgroup.com>]
> Sent: Wednesday, December 03, 2014 11:28 AM
> To: janina@rednote.net<mailto: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> [mailto: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<tel:%2B1.443.300.2200>
>                       sip:janina@asterisk.rednote.net<mailto:sip%3Ajanina@asterisk.rednote.net>
>               Email:  janina@rednote.net<mailto:janina@rednote.net>
>
> Linux Foundation Fellow
> Executive Chair, Accessibility Workgroup:     http://a11y.org<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<tel:%2B1.443.300.2200>
>                       sip:janina@asterisk.rednote.net<mailto:sip%3Ajanina@asterisk.rednote.net>
>               Email:  janina@rednote.net<mailto:janina@rednote.net>
>
> Linux Foundation Fellow
> Executive Chair, Accessibility Workgroup:     http://a11y.org<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/

>
>
>
>
>