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



From: Steve Faulkner <faulkner.steve@gmail.com>
To: Bryan Garaventa <bryan.garaventa@whatsock.com>,
            public-aria@w3.org
Cc: Joseph Scheuhammer <clown@alum.mit.edu>, Richard
            Schwerdtfeger/Austin/IBM@IBMUS, Joanmarie Diggs
            <jdiggs@igalia.com>, Dominic Mazzoni <dmazzoni@chromium.org>,
            James Craig <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


--

Regards

SteveF
Current Standards Work @W3C

On 21 December 2015 at 18:41, Bryan Garaventa <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