RE: How the W3C Text Alternative Computation Works

I agree if the current node is referenced, which the article states. This is supported in the Text Alternative Computation at
http://www.w3.org/TR/accname-aam-1.1/#h-mapping_additional_nd_te


Where it states:

“A. If the current node is Hidden and is not referenced by aria-labelledby or aria-describedby, nor referenced by a native host language text alternative element or attribute, return the empty string.”

This reads to me as, if a child element is hidden, that child element is not the ‘current’ node specifically referenced by aria-labelledby or aria-describedby, because it’s a different node.

Otherwise, if it was meant to expose all children as well, this would have to be rewritten to cover the statement below, also within that document:

“An 'owned element' is any DOM descendant of the element, any element specified as a child via aria-owns, or any DOM descendant of the owned child.”

So it would also have to include verbiage that includes all ‘owned’ elements as part of the naming calculation regardless if they are hidden.

The definition of hidden within this document states:

“Indicates that the element is not visible or perceivable to any user. An element is considered hidden if it or any one of its ancestor elements is not rendered or explicitly hidden.”

This is where the issue of inheritance comes into play within the browser.

It doesn’t make any sense to me as a developer not to be given any method for explicitly hiding extraneous content if I want to within an accessible label, and if you expose everything regardless without allowing for this capability, it will limit the options for accessible labelling, not enhance it.

That’s the way this reads to me anyway, and I knew I was opening a can of worms by writing this, but this shows how many people truly don’t understand what this algorithm is supposed to be.

Also, the following test shows that hidden content is currently not included within the naming calculation within major browsers:

<form>
<label for="email"> Email
<span style="display: none;"> Error </span>
</label>
<input type="text" id="email" />
</form>

The Name property within the latest version of Firefox and Chrome is “Email”, not “Email error”, just confirmed on Win7.

From: Richard Schwerdtfeger [mailto:schwer@us.ibm.com]
Sent: Tuesday, December 22, 2015 6:01 AM
To: Steve Faulkner <faulkner.steve@gmail.com>
Cc: Bryan Garaventa <bryan.garaventa@whatsock.com>; Joseph Scheuhammer <clown@alum.mit.edu>; Dominic Mazzoni <dmazzoni@chromium.org>; James Craig <jcraig@apple.com>; Joanmarie Diggs <jdiggs@igalia.com>; public-aria@w3.org
Subject: Re: How the W3C Text Alternative Computation Works


This is pretty straight forward.

You have a aria-labelledby pointing to a div. From  there  you get name from contents. It does not matter if the content is hidden or display:none. You concatenate all the text content. There is no difference between display:none or visibility:hidden. Visibility:hidden is essentially not displaying the content but leaving this hole in the display to wrap around. It is still content that is not displayed by the author.

Done.

The accessible name should be: "Email address: Error: A valid email address is required."

If we need clarity in the spec. but there should be no difference. for visibility: hidden vs. display: none.   It is not displayed as intended by the author.

The error message should be take outside the containing dive with the parentID id. Remember we are going to have an error relationship now.

Rich Schwerdtfeger

[Inactive hide details for Steve Faulkner ---12/22/2015 03:36:31 AM---Hi Brian, am unclear about the example using visbility:hid]Steve Faulkner ---12/22/2015 03:36:31 AM---Hi Brian, am unclear about the example using visbility:hidden The Name for this edit field is “Count

From: Steve Faulkner <faulkner.steve@gmail.com<mailto:faulkner.steve@gmail.com>>
To: Bryan Garaventa <bryan.garaventa@whatsock.com<mailto:bryan.garaventa@whatsock.com>>, public-aria@w3.org<mailto:public-aria@w3.org>
Cc: Joseph Scheuhammer <clown@alum.mit.edu<mailto:clown@alum.mit.edu>>, Richard Schwerdtfeger/Austin/IBM@IBMUS, Joanmarie Diggs <jdiggs@igalia.com<mailto:jdiggs@igalia.com>>, Dominic Mazzoni <dmazzoni@chromium.org<mailto:dmazzoni@chromium.org>>, James Craig <jcraig@apple.com<mailto:jcraig@apple.com>>
Date: 12/22/2015 03:36 AM
Subject: Re: How the W3C Text Alternative Computation Works

________________________________



Hi Brian, am unclear about the example using visbility:hidden
The Name for this edit field is “Country”, and the Description is “Choose the country where you currently reside.”

The reason for this, is that the naming calculation allows for aria-labelledby and aria-describedby to reference hidden elements, however this is only true if it is the referenced element or one of its parent elements that is hidden. This is possible here using display:none, because this CSS property is not inheritable, and thus is not applied to the child span element.
The following examples demonstrate this difference:

<div id="parentId">
  Email address:
  <input aria-labelledby="parentId" type="text" />
  <div class="validationError" style="display:none;" aria-hidden="false" >
    Error: A valid email address is required.
  </div>
</div>

I don't see in the spec[1] where the difference between CSS display:none and CSS visbility:hidden is defined. In  IE and Firefox on windows and chrome,safari, etc on iOS the description is exposed and is announced
test file:
http://codepen.io/stevef/pen/LGZQvr


note: tabindex="-1" is added to the hidden div for IE, this is due to a known limitation of IE's support for aria-describedby.

I also don't think your interpration is helpful as it adds another level of complexity to an already complex algorithm. There should be no difference between the effect of display:none and visibility:hidden on accessible name calculation

[1] rawgit.com/w3c/aria/master/accname-aam/accname-aam.html<http://rawgit.com/w3c/aria/master/accname-aam/accname-aam.html>


--

Regards

SteveF
Current Standards Work @W3C<http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>

On 21 December 2015 at 18:41, Bryan Garaventa <bryan.garaventa@whatsock.com<mailto:bryan.garaventa@whatsock.com>> wrote:
Hello,
Recently I was asked to write a blog post explaining the naming calculation and how it works, which I've published at
http://www.ssbbartgroup.com/blog/how-the-w3c-text-alternative-computation-works/


I believe I've covered everything of note that should help explain the algorithm and how it works. The only controversial aspect is
the section regarding aria-hidden='false', however since this is written in the spec, this is the only way I see that logically
explains how this would impact the naming calculation. I'll pass this around to spread the word; the more who understand the
algorithm the easier it is to understand how ATs use it. Please let me know if anything is missing.

Also, I wanted to thank Google for stepping up and doing an excellent job updating the recursive naming calculation with the most
recent release of Chrome Canary, which now has the closest recursion algorithm match for the naming calculation as compared with any
of the other browsers. This is really a great achievement, and all those who worked on this to get this done so quickly, should be
congratulated since it will have a significant impact in the future.

All the best,
Bryan