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

No problem, this is complicated, which is why I tried to break it down.

Regarding 1, actually I meant for textarea to be included with input+type=text in the blanket statement where it states "(for a form control)" and "(for a text form control)", both of which include all types of text controls.

Dominic helped me with the hierarchy for how these are listed in order of preference within the browser, so it's not actually meant to be a grouping of related element types, but rather an If-Or statement to show how when one failes the criteria for that step it falls through to the next in the list until it reaches the bottom if none of them match.

Regarding 2, you are right, 'title' is the fallback Name in most cases, so I'll change that in the list. However there is an exception to this which I just tested in FF and Chrome, if you have an input+type="submit" or "button" or "reset", as well as a 'title', it will not set the Name, only the Description.

Presumably this is why 'title' appears before the input elements with these type declarations in the order of preference, second to the last, because it never applies there in the browser.

Also, since 'title' applies to all element types that receive a Name, it has to be at the end of the list because it doesn't just apply to form fields.

Regarding 3, the way that CSS pseudo elements work in the browser is using the :before or :after pseudo elements, which are either prepended in the case of :before or appended in the case of :after to the container element that the CSS content is applied to. This only works on elements that can include innerHTML, so this doesn't work on elements that don't, such as img or input elements.

So when these elements are rendered either at the beginning or end of such containers, this is where this content appears in the naming calculation as part of the content within that node structure.

You can actually try this out using the demo code I put in the article for this and run it in Firefox. If you set focus to the link using a screen reader like JAWS or NVDA, you will hear the new content announced.

Actually I don't remember where this behavior is specifically referenced in the spec, hopefully somebody else here does. The spec for CSS content is still being worked on isn't it?

Regarding 4, I'm not sure, because when something has no role there is no way to programmatically predict its purpose. So it may at sometimes be meant to be a replacement or sometimes meant to be an accompaniment like a named region. There is no way to tell.





-----Original Message-----
From: Birkir Gunnarsson [mailto:birkir.gunnarsson@deque.com] 
Sent: Tuesday, December 22, 2015 12:45 PM
To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
Cc: Steve Faulkner <faulkner.steve@gmail.com>; public-aria@w3.org; 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

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-computat

> ion-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 22:48:48 UTC