RE: RE: Re: Re: Seeking feedback on draft of section on naming and describing

Hi,
In this case, it would be:
accName: "Hello screen reader world"

FYI, To test this, I just copied the code and pasted it into the test edit field at
https://whatsock.github.io/w3c-alternative-text-computation/Editable%20Live%20Input%20AccName%20Test.html


I’m happy to confirm whenever you like, but doing this might be faster than the time it takes me sometimes to reply. ☺

This should reflect the latest discussions we have had on AccName at present, but does not include label encapsulation as yet or role=radiogroup in combo with the legend role for naming in the same way that role=group does. I’ll update this soon with these changes.

All the best,
Bryan


Bryan Garaventa
Principal Accessibility Architect
Level Access, Inc.
Bryan.Garaventa@LevelAccess.com
415.624.2709 (o)
www.LevelAccess.com<http://www.levelaccess.com/>

From: Carolyn MacLeod <Carolyn_MacLeod@ca.ibm.com>
Sent: Thursday, May 23, 2019 11:55 AM
To: Bryan Garaventa <bryan.garaventa@levelaccess.com>
Cc: public-aria-practices@w3.org; public-aria@w3.org
Subject: Re: RE: Re: Re: Seeking feedback on draft of section on naming and describing

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Hi Bryan,

So for a similar example that uses aria-label:

<button id="test">Hello <span aria-label="screen reader "></span>world</button>

Would the button's name be "Hello screen reader world" or "Hello world"?

Carolyn


----- Original message -----
From: Bryan Garaventa <bryan.garaventa@levelaccess.com<mailto:bryan.garaventa@levelaccess.com>>
To: "a11ythinker@gmail.com<mailto:a11ythinker@gmail.com>" <a11ythinker@gmail.com<mailto:a11ythinker@gmail.com>>, 'Carolyn MacLeod' <Carolyn_MacLeod@ca.ibm.com<mailto:Carolyn_MacLeod@ca.ibm.com>>
Cc: "annabbott@gmail.com<mailto:annabbott@gmail.com>" <annabbott@gmail.com<mailto:annabbott@gmail.com>>, "public-aria-practices@w3.org<mailto:public-aria-practices@w3.org>" <public-aria-practices@w3.org<mailto:public-aria-practices@w3.org>>, "public-aria@w3.org<mailto:public-aria@w3.org>" <public-aria@w3.org<mailto:public-aria@w3.org>>
Subject: [EXTERNAL] RE: Re: Re: Seeking feedback on draft of section on naming and describing
Date: Fri, May 17, 2019 8:25 PM



Actually, in the example as you currently have it coded, the name is

accName: "Helloworld"



The reason being that, only elements that are directly hidden and referenced by aria-labelledby or aria-describedby will be parsed, and not those that have hidden parent elements instead. I was asked about a year ago to make this change when I mentioned this scenario during one of our ARIA WG meetings, and the group verdict at that time was that the spec says that only elements that are specifically hidden will be exposed, and no others. If the group wants to reverse this, then we need to speak about it at one of the next ARIA WG meetings to make a decision about it, and I’ll make whatever change is needed then.



If you change your example to the below code though, your button name changes to: accName: "HelloARIAdevelopersworld"



<button id="test">Hello<span aria-labelledby="word2"></span><span aria-labelledby="word3"></span>world</button>

<div>

  <span hidden id="word2">ARIA</span>

  <span hidden id="word3">developers</span>

</div>



I know everybody’s brain was fried by the end of those meetings, but at the end I asked for people to make a decision because I had two choices, (1) I could ignore the ambiguity of the spec and insist that aria-labelledby is only allowed on the root node, or (2) I can change the AccName Prototype to reflect what the spec actually says and make it allowable to use this attribute on one iteration of child nodes within the root node. Jonie insisted that we needed to make sure the prototype reflected the spec and not the other way around, and nobody disagreed, so that’s what I did. This is now live in the AccName Prototype code at

https://whatsock.github.io/w3c-alternative-text-computation/Editable%20Live%20Input%20AccName%20Test.html




If you want the opposite of this though, then we need to discuss that too in one of the next meetings.



My goal is to establish a common outline of these behaviors, so I’ll need to work these things out before drafting real spec text for it, which is why I wrote the outline I sent through last week. This behavior as I’ve written above is actually described and included in that outline, so I encourage you and others to please read it. The difference between key terms like implicitly hidden as opposed to explicitly hidden elements is documented there as well.



Have a great weekend,

Bryan













Bryan Garaventa

Principal Accessibility Architect

Level Access, Inc.

Bryan.Garaventa@LevelAccess.com<mailto:Bryan.Garaventa@LevelAccess.com>

415.624.2709 (o)

www.LevelAccess.com<http://www.levelaccess.com/>



From: a11ythinker@gmail.com<mailto:a11ythinker@gmail.com> <a11ythinker@gmail.com<mailto:a11ythinker@gmail.com>>
Sent: Friday, May 17, 2019 3:41 PM
To: Bryan Garaventa <bryan.garaventa@levelaccess.com<mailto:bryan.garaventa@levelaccess.com>>; 'Carolyn MacLeod' <Carolyn_MacLeod@ca.ibm.com<mailto:Carolyn_MacLeod@ca.ibm.com>>
Cc: annabbott@gmail.com<mailto:annabbott@gmail.com>; public-aria-practices@w3.org<mailto:public-aria-practices@w3.org>
Subject: RE: Re: Re: Seeking feedback on draft of section on naming and describing



CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.



Bryan,



Actually, I am a bit confused. At the meeting, I thought we agreed that we want to preserve at least one of the current implementations (either Firefox or Chrome), I don’t recall which. Neither Chrome nor Firefox follow what you have prescribed in your note.



Here is the test case we used:



<button>Hello<span aria-labelledby="word2"></span><span aria-labelledby="word3"></span>world</button>

<div style="display:none">

  <span id="word2">ARIA</span>

  <span id="word3">developers</span>

</div>



Chroem result is “Hello ARIA developers world”

Firefox result is “Helloworld”



If I follow what you are saying in your note, the result should be “Hello ARIA world”.



Personally, I think the Chrome result is most intuitive. If we simply have the rule that there is no chaining, wouldn’t that be enough to avoid infinite loops?



Best,

Matt



From: Bryan Garaventa <bryan.garaventa@levelaccess.com<mailto:bryan.garaventa@levelaccess.com>>
Sent: Thursday, May 16, 2019 5:29 PM
To: Carolyn MacLeod <Carolyn_MacLeod@ca.ibm.com<mailto:Carolyn_MacLeod@ca.ibm.com>>
Cc: a11ythinker@gmail.com<mailto:a11ythinker@gmail.com>; annabbott@gmail.com<mailto:annabbott@gmail.com>; public-aria-practices@w3.org<mailto:public-aria-practices@w3.org>
Subject: RE: Re: Re: Seeking feedback on draft of section on naming and describing



Hi,

There is one thing I wanted to mention within the aria-labelledby section, which is where it states that aria-labelledby is only allowed on the element being computed and not on any of its child elements.



In practice I understand why it is desirable to say this, but this came up during the FTF meeting and we determined that the spec actually allows this on child nodes, and I was asked to make sure this was maintained.



So, aria-describedby is only allowed to be followed on the root node (button for example), however aria-labelledby can be present on a child node of button and will be followed regardless.



Here are the caveats:

  1.  The aria-labelledby referrals can only be followed once, and not on any subsequent elements if encountered there such as by chaining aria-labelledby attributes together on different elements. Only the first will be followed and no others.
  2.  You cannot nest aria-labelledby references, where you have aria-labelledby on the root node as well as on a child node of the root node. In this last case, only the root node will be traversed and none of the child nodes will be parsed.
  3.  Any node that is parsed in the tree as a child or owned element via aria-owns, or as part of an aria-labelledby or aria-describedby traversal, can only be processed once and will be ignored by any other references to itself later by any other attribute or process during this computation. This prevents infinite loops from occurring. So, only the first instance of this node will be processed when encountered in the order of the naming computation, and not by any others after that.



Hopefully this makes sense.



All the best,

Bryan





Bryan Garaventa

Principal Accessibility Architect

Level Access, Inc.

Bryan.Garaventa@LevelAccess.com<mailto:Bryan.Garaventa@LevelAccess.com>

415.624.2709 (o)

www.LevelAccess.com<http://www.levelaccess.com/>



From: Carolyn MacLeod <Carolyn_MacLeod@ca.ibm.com<mailto:Carolyn_MacLeod@ca.ibm.com>>
Sent: Tuesday, May 14, 2019 12:09 PM
To: Carolyn MacLeod <Carolyn_MacLeod@ca.ibm.com<mailto:Carolyn_MacLeod@ca.ibm.com>>
Cc: a11ythinker@gmail.com<mailto:a11ythinker@gmail.com>; annabbott@gmail.com<mailto:annabbott@gmail.com>; public-aria-practices@w3.org<mailto:public-aria-practices@w3.org>
Subject: Re: Re: Re: Seeking feedback on draft of section on naming and describing



CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.



When you write the "Naming by Encapsulation with a Label" section, you might want to specifically mention form elements, and refer back to Cardinal Rule 2: Prefer Visible Text, and Cardinal Rule 3: Prefer Native Techniques.



----- Original message -----
From: "Carolyn MacLeod" <Carolyn_MacLeod@ca.ibm.com<mailto:Carolyn_MacLeod@ca.ibm.com>>
To: annabbott@gmail.com<mailto:annabbott@gmail.com>
Cc: a11ythinker@gmail.com<mailto:a11ythinker@gmail.com>, annabbott@gmail.com<mailto:annabbott@gmail.com>, public-aria-practices@w3.org<mailto:public-aria-practices@w3.org>
Subject: [EXTERNAL] Re: Re: Seeking feedback on draft of section on naming and describing
Date: Tue, May 14, 2019 2:24 PM


Great feedback from Ann.

Here's a few more:



1. Typo, aria-labeledby with one l in "5.3.2.3 Naming with Referenced Content Via aria-labeledby"



2. Consider simplifying:
"There are certain elements that get their name from the content they contain."

by removing a couple of words, as follows:

"Certain elements get their name from the content they contain."



3. Use "affects" with an "a" instead of "effects" with an "e" in the following sentence:

"The aria-label attribute effects assistive technology users..."



4. Clarify the following sentence:

"Note that while using aria-labelledby is similar in this situation to using an HTML label element with the for attribute, one significant difference is that browsers do not automatically make clicking on the label activate the element; that is an author responsibility."
as follows:

"Note that while using aria-labelledby is similar in this situation to using an HTML label element with the for attribute, one significant difference is that browsers do not automatically make clicking on the labelling element activate the labelled element; that is an author responsibility."



5. "inputtype="checkbox"" needs space, and needs to be in <code> element



6. Consider changing "such as" to "including" in:

"It has the highest precedence when browsers calculate accessible names, i.e., it overrides names from child content and all other naming attributes, such as aria-label."
so that it reads:

"...all other naming attributes, including aria-label."



(I stopped reading at the first To-do).



Carolyn



----- Original message -----
From: Ann Abbott <annabbott@gmail.com<mailto:annabbott@gmail.com>>
To: Matt King <a11ythinker@gmail.com<mailto:a11ythinker@gmail.com>>
Cc: "public-aria-practices@w3.org<mailto:public-aria-practices@w3.org>" <public-aria-practices@w3.org<mailto:public-aria-practices@w3.org>>, Ann Abbott <annabbott@gmail.com<mailto:annabbott@gmail.com>>
Subject: [EXTERNAL] Re: Seeking feedback on draft of section on naming and describing
Date: Tue, May 14, 2019 11:24 AM


Review  of https://raw.githack.com/w3c/aria-practices/zcorpan/labelling-describing/aria-practices.html#names_and_descriptions




Sectioin 5. Providing Accessible Names and Descriptions:typo in second sentence. " While doing so is straight forward for most elements, technical mistakes that can have devistating impacts..." should be "While doing so is straight forward for most elements, technical mistakes that can have devastating impacts..."



Sectioin 5. Providing Accessible Names and Descriptions: bullets within this section should be formatted as EITHER sentence case OR title case, match the heading of specific subsection and.listed in order of preference. Change to numbered list from bulleted list to denote preference order. Should probably be two lists: one for naming and a second list for describing. Also each listitem should be a link to that specific subsection which should also be ordered by preference. .

Example using title case and two lists ordered by preference:

  *   Naming

1.    Naming by Encapsulation with a Label.

2.    Naming by Referencing Content Via aria-labelledby.

3.    Naming with a String Attribute Via aria-label.

4.    Naming with Child Content.

5.    Naming with Legends and Captions.

6.    Fallback Names Derived from Titles and Placeholders.

  *   Describing

1.    Describing by Referencing Content with aria-details.

2.    Describing by Referencing Content with aria-describedby.

3.    Fallback Descriptions Derived from Titles and Placeholders. (Note: no section exists for this. Either add section or remove bullet.)

Sectioin 5.3.1.3 Rule 3: Prefer Native Techniques follows Section 5.3.1.2 Rule 2: Prefer Visible Text but, based on order of preference, 5.3.1.3 Rule 3: Prefer Native Techniques should be listed first.

Reorder subsections under 5.3.2 Naming Techniques to match order of listitems under Sectioin 5. Providing Accessible Names and Descriptions.



Because naming and describing are two different constructs, care must be taken to not confuse the reader by using 'describing' or 'description' or "descriptiveness" when discussing or defining naming.

•         5.3.1.5 Rule 5: Compose Brief, Useful Names

In the same way that visually crowded screens reduce usability, excessively long or insufficiently distinct and descriptive (remove "and descriptive") accessible names can make a user interface very difficult, or even impossible, to use for someone who relies on a non-visual form of the user interface. In other words, for a web experience to be accessible, the names must be effective. The below section on Composing Effective and User-friendly Accessible Names<https://raw.githack.com/w3c/aria-practices/zcorpan/labelling-describing/aria-practices.html#naming_effectively> provides guidance for striking an effective balance between brevity and descriptiveness (change "descriptiveness" to "effectiveness" or "usefulness").

#4 Warning under 5.3.2.2 Naming with a String Attribute Via aria-label: typo
"When a user interface is translated into multiple languages, ensure that aria-lable values..." should be " When a user interface is translated into multiple languages, ensure that aria-label values..."



5.3.2.3 Naming with Referenced Content Via aria-labeledby includes a "To-do" for code examples.

#1 Warning under 5.3.2.3 Naming with Referenced Content Via aria-labeledby: typo

" The aria-labelledby property cannot be chained, i.e., if an element with aria-labelled by references..." should be " The aria-labelledby property cannot be chained, i.e., if an element with aria-labelledby references..."



All subsequent sections contain To-do notations, indicating they are not yet complete - review is pending completion.





Kind Regards,
Ann
annabbott@gmail.com<mailto:annabbott@gmail.com>
512-451-8267



On Mon, May 13, 2019 at 2:33 AM <a11ythinker@gmail.com<mailto:a11ythinker@gmail.com>> wrote:

Hi All,



I’d like to discuss the naming and describing section on Tuesday. Please read the current draft, which is about 80% complete, here:

https://raw.githack.com/w3c/aria-practices/zcorpan/labelling-describing/aria-practices.html#names_and_descriptions




This is a really important section. Please give it a read so we can have substantive discussion.



At this point, I think I have built all of Jon’s feedback into the outline. Although, not all the content is complete; there is still several to-do’s related to that. There are some other placeholder to-do items as well.



Some goals include:

  1.  Comprehensive: all important topics/issues should be addressed.
  2.  Easy to read: clarity of language and simplicity of examples is paramount.
  3.  Easy to scan for specific information; an information architecture that is easy to follow.
  4.  Practical, practical, practical …
  5.  Witout using anti-patterns, help people avoid naming blunders.



Thanks,

Matt