Sync Accessible Name SC language with existing WCAG terminology

[steverep]

The terms used in the "Accessible Name" SC are not at all synced with existing terminology from WCAG 2.0. The following changes are made to fix this:

1. Replace "control" with "user interface component" and link to glossary
2. Link to glossary for "label". Note that the definition of label implies it is visible (i.e. "presented to all users"), so the initial clause may not really be necessary, but a label can also be a text alternative so this criterion should refer to labels that include text.
3. Instead of adding an "accessible name" term, we really should be using the existing "name" term in the glossary used in 4.1.2 and 1.1.1. It's the same thing with a very different definition.
4. Rename SC handle to "Label in Name" to better describe the intent instead of "Accessible Name" which applies to many criteria.

Issue discussion is in #371.

[michael-n-cooper]

On the whole I think this does achieve better harmonization with existing WCAG 2.0. However, the proposed wording is less obvious about the intent of the SC, so I think it will require some "selling" in the WG. But the goal of re-using WCAG 2.0 terms that are correct even if superficially awkward should have some weight.

Removing the note at the end of the SC about best practice is a more substantive change. On one hand, wording of that note meant it didn't correctly say what I think it was meant to say, otoh it was calling something additional out that might have been viewed as important to the SC (even though notes are non-normative). So I think it will be best either to clean up the wording of that note and keep it in the SC, or make sure it is clearly represented in the Understanding content and get WG agreement that that is good enough for that point.

[steverep]

@michael-n-cooper, I added the note back in and altered it to use the right terminology. I think it is stating what was actually intended now.

@awkawk, pending agreement this is amended per the teleconference, this is now ready to merge.

[steverep]

Closes #371

[DavidMacDonald]

WCAG uses the word control in 1.1.1 which has been removed from the text of the SC based upon it not being consistent with existing WCAG language. I would say ithe use of "control" is consistent with WCAG.

Controls, Input: If non-text content is a control or accepts user input, then it has a name that describes its purpose. (Refer to Guideline 4.1 for additional requirements for controls and content that accepts user input.)
https://www.w3.org/TR/WCAG20/#text-equiv​ ​

It is part of the definition of User Interface Component.
https://www.w3.org/TR/WCAG20/#user-interface-componentdef
​
A​ User interface component is usually used in our standard as a group of code elements that are perceived as one control.

​I think this issue needs more revision.​ It will be easier to understand and more consistent with its meaning as something like this:

Where an active control has a visible <a>label</a>, the <a>name</a> for the control includes the text string used for its visible label.

Note: A best practice is to place the text string​ ​that is visible to sighted users ​at the start of the ​name.

Otherwise it needs the addition of visible label:

For active user interface components with labels that include text <add>or images of text</add>, the name includes the text of the label.

The new wording dropped "visible label", and sometimes a visible label is an image, want to ensure this doesn't pass. <button aria-label="go"><img src="go.jpg"></button><input aria-label="search" ...>

[steverep]

Hmmm.... good catch, David. I agree with this change. The original wording is actually very unclear here because it refers to the "text string" of the "visible label", so it sort of eliminates an image of text as a possible label. My version catches the fact that a label is always visible per the definition, and also that a label could have no visible text (e.g. an icon)... but I missed the possibility of an image of text.

@awkawk, do you think we should fix this here or put in a new issue? I know you also wanted to remove "active" as well anyway (which I think I agree with).

[DavidMacDonald]

I wouldn't remove active. Sometimes the label becomes visible on focus which I equate to "active"

[DavidMacDonald]

I think we can keep the term Accessible Name, put a link to the "name" definition, andnadd brackets after the word "name"

Name (accessible name)
_ ...defintion here ..._

[DavidMacDonald]

I wouldn't remove active. Sometimes the label becomes visible on focus which I equate to "active"

[steverep]

Should resolve #453 and resolve #454

[johnfoliot]

Reviewing the proposed language, and a question: what does this mean? <p class="note">A best practice is to place the text string at the start of the text string.</p> It appears to be a circular sentence, with no actual meaning (where else would you start the text string if not the beginning?). Can we get some editorial clarity please? Do we need to file a separate issue for this? JF

…

On Mon, Oct 9, 2017 at 11:20 AM, Steve Repsher ***@***.***> wrote: Should resolve #453 <#453> and resolve #454 <#454> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#377 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABK-c2vla7RtDR3ghLKbcf2-QR62gb0zks5sqke9gaJpZM4PR1lX> .

-- John Foliot Principal Accessibility Strategist Deque Systems Inc. john.foliot@deque.com Advancing the mission of digital accessibility and inclusion

[steverep]

@johnfoliot, that's the existing language, not the proposal here. When merged, it will read: "A best practice is to have the text of the label at the start of the name."

[jnurthen]

I'm generally in favour of this change but request, if it is possible, a non-normative note within the definition of name which points to the aria definition of accessible name in the ARIA spec so it is clear to all that this is what we are talking about.

[steverep]

Should also resolve #504