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

Birkir,

I think the last note is intended to address the inconsistent 
implementation of aria-hidden="false" on content that is not displayed 
i.e.,  cautioning authors who are trying to reveal content only to 
non-visual users and not to others. In that case, leaving off aria-hidden 
would not achieve the effect.

That said, the current draft spec text does not address 
aria-hidden="false". It describes the meaning of aria-hidden="true" 
without saying so.

At this time, IE is the only browser I know of that exposes <element 
aria-hidden="true" style="display:none">my content only for blind 
readers</element> to screen readers. Last January, at the face to face at 
Mozilla, I thought there was agreement from Mozilla to also implement the 
same behavior, but it is not yet done.

I have the feeling that there are still a lot of us who are not entirely 
comfortable with this approach to the problem.

Matt King
IBM Senior Technical Staff Member
I/T Chief Accessibility Strategist
IBM BT/CIO - Global Workforce and Web Process Enablement 
Phone: (503) 578-2329, Tie line: 731-7398
mattking@us.ibm.com



From:   Birkir Gunnarsson <birkir.gunnarsson@deque.com>
To:     Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>, 
Cc:     James Craig <jcraig@apple.com>, Dominic Mazzoni 
<dmazzoni@google.com>, Janina Sajka <janina@rednote.net>, "W3C WAI 
Protocols & Formats" <public-pfwg@w3.org>
Date:   12/17/2014 04:15 PM
Subject:        Re: Spec text indicates aria-hidden is not optional (Re: 
48-Hour Call  for Consensus (CfC); Publish 1 ARIA FPWD & 2 ARIA 
Heartbeats)



I like the spec text.
I would propose a very minor modification to the aria-hidden="false"
cautionary paragraph.
currently:
"....such as display:none or visibility:hidden in CSS, or the
hidden attribute in HTML ..."
amended:
"such as display:none or visibility:hidden in CSS, type="hidden" on
<input> elements, or the
hidden attribute in HTML..."
and add the sentence:
When an html element contains such content it is recommended that
authors remove the aria-hidden attribute rather than setting its value
to "false".



On 12/17/14, Bryan Garaventa <bryan.garaventa@ssbbartgroup.com> wrote:
> Thanks, I'll bookmark this for future reference.
>
> The updated aria-hidden spec text looks good, thanks again. I like that
> there is a cautionary note regarding the use of aria-hidden='false' on 
CSS
> hidden elements, since this will likely be a point of confusion for a 
while
> until it's more globally supported.
>
>
> From: James Craig [mailto:jcraig@apple.com]
> Sent: Wednesday, December 17, 2014 10:22 AM
> 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)
>
> No. Any URL with a long hash like your link is specific to a particular
> commit. You want the master branch instead.
>
> Here's the master branch editor's draft.
> https://rawgit.com/w3c/aria/master/aria/aria.html#aria-hidden
>
>
> On Dec 16, 2014, at 8:02 PM, Bryan Garaventa
> <bryan.garaventa@ssbbartgroup.com<
mailto:bryan.garaventa@ssbbartgroup.com>>
> wrote:
>
> 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/
>>
>>
>>
>>
>>
>
>