Re: [WebAIM] How the W3C Text Alternative Computation Works

Good job Bryan!
I have a couple of specific comments that I will probably send you off-list.
I have 3 questions for you and the list:
1. When you are listing the labeling techniques, you use a list of 11
elements, where you specify how to provide accessible name using
native html for different types of elements.
- value for input of type submit, reset etc.
- alt for images and <area> tags
and so on.
You leave out a couple of elements, such as textarea, I can send you a
slightly altered list I built based on your list.
These are not grouped together in your accessible name algorithm description.
I would put all html accessible name techniques into an unordered list
and call it "native html techniques"" or similar.
<ol>
<li>aria-labelledby</li>
</li>aria-label</li>
<li>Native html techniques
<ul><li>label for a form field</li>
<li>value for input of type x y z</li>
..
</ul>
<
<li>The title attribute</li>
/li>
...
</ol>

2. You do not say that the title element of any html element is a
valid source of the element's accessible name if no other source is
available. This is stated in the WAI_ARIA specification's accessible
name calculation section.
My understanding is that this technique should be listed as accessible
name source #4 in the ordered list above (after aria-labelledby,
aria-label, and native html techniques.
Has something changed?

3. How does the CSS content property come into the accessible
description algorithm?
Can you provide clearer text explaining the relationship between CSS
content and the accessible description?
Something like: " The content attribute is exposed as part of the
element content when focus goes on the element", or similar.
If you can provide a reference to spec where it is stated taht user
agents/acsistive technology should expose this info.

A bonus question
4. Question for everybody on the list (and I might break this into a
separate email)
How should user agents/assistive technologies treat aria-label or
aria-labelledby on divs and spans without a role?

<div aria-label="My favorite Mexican Food">Chipotle chicken with no e-coli</div>

Is the accessible name of this element

"My favorite Mexican food"
or
"Chipotle Chicken"
?
According to the algorithm it should be the value of the aria-label,
and the text content of the element should be ignored.
But I am not sure if authors are allowed to use aria labeling
techniques on elements without a role.
I know it is not exposed to end users of most screen readers.
Thanks
-Birkir



On 12/22/15, Bryan Garaventa <bryan.garaventa@ssbbartgroup.com> wrote:
> Exactly, that’s why I said it was controversial.
>
> A while back we added aria-hidden=”false” to the spec so that it exposes
> hidden content to ATs.
>
> If this is done however, then it has to have an impact on the naming
> calculation. There is no way it cannot.
>
> I agree that this isn’t clear in the spec, mainly because I don’t think it’s
> clear to anybody here either.
>
>
> From: Steve Faulkner [mailto:faulkner.steve@gmail.com]
> Sent: Tuesday, December 22, 2015 7:36 AM
> To: public-aria@w3.org
> Cc: Joseph Scheuhammer <clown@alum.mit.edu>; Dominic Mazzoni
> <dmazzoni@chromium.org>; James Craig <jcraig@apple.com>; Joanmarie Diggs
> <jdiggs@igalia.com>; Richard Schwerdtfeger <schwer@us.ibm.com>
> Subject: Re: [WebAIM] How the W3C Text Alternative Computation Works
>
> Hi again Bryan,
> another example that i am unclear about is:
>
> Where the Name of the edit field is “Email address:”, because the content
> that includes aria-hidden=”true” is excluded from the naming calculation.
>
> However, aria-hidden has another purpose that contradicts this behavior in
> the naming calculation, which occurs when aria-hidden is explicitly set to
> “false”. When applied on an explicitly hidden element using CSS for example,
> this content is included in the naming calculation even though the element
> remains hidden using CSS.
>
> <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 am unsure that your prediction is correct, either way it is not reflected
> in implementations, of the browsers i tested: latest firefox, chrome and IE,
> all expose only "Email address:" as the accessible name.
> test file: http://codepen.io/stevef/pen/gPMKeZ
>
> --
>
> Regards
>
> SteveF
> Current Standards Work
> @W3C<http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>
>
> On 21 December 2015 at 18:45, 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
>
> _______________________________________________
> To manage your subscription, visit http://list.webaim.org/
> List archives at http://webaim.org/discussion/archives
> Address list messages to
> webaim-forum@list.webaim.org<mailto:webaim-forum@list.webaim.org>
>
>

Received on Tuesday, 22 December 2015 20:45:58 UTC