Skip to content
This repository has been archived by the owner on Jun 30, 2018. It is now read-only.

Sync Accessible Name SC language with existing WCAG terminology #371

Closed
steverep opened this issue Sep 7, 2017 · 10 comments
Closed

Sync Accessible Name SC language with existing WCAG terminology #371

steverep opened this issue Sep 7, 2017 · 10 comments

Comments

@steverep
Copy link
Member

steverep commented Sep 7, 2017

The terms used in the "Accessible Name" SC are not at all synced with existing terminology from WCAG 2.0. I'd suggest the following changes to remedy 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. Given the last point, and the fact that there are several criteria which come together to produce accessible names, I think this criterion needs a less generic handle. I would suggest something like "Label in Name".

I think something like this would work:

Label in Name: For active user interface components with labels that include text, the name includes the text of the label.

@jake-abma
Copy link
Contributor

+1 for @steverep

As for the label this is indeed not necessary to mention “visible” as this is implicit

For “name” though I see the point of staying close to 4.1.2 but the term “accessible name” covers the meaning much better, clearer to explain and understand and is also how it’s mentioned from the AAM documents: https://www.w3.org/TR/accname-aam-1.1/#dfn-accessible-name and also mentioned in ARIA as Accessible Name: https://www.w3.org/TR/wai-aria-1.1/#dfn-accessible-name

Of course as we’re not changing 2.0 there’s a mismatch between these documents…

@joshueoconnor
Copy link
Contributor

joshueoconnor commented Sep 21, 2017

I agree with @steverep in principle - using control is better than user interface component - (unless sometimes a user interface component is somehow NOT a control)..

I realise I may need to get out more...

@joshueoconnor
Copy link
Contributor

Note. I think the preference for 'Accessible Name' over 'name' comes from a11y geeks who do DOM, A11y tree inspection. It's an interesting discussion as to whether its better to use one term over another. I do see an advantage to calling out the 'Accessible Name' as it implies that this is explicitly loaded in the DOM or A11y Tree.

@steverep steverep self-assigned this Sep 21, 2017
@steverep
Copy link
Member Author

@joshueoconnor, I think the discussion of user interface component vs. control and name vs. accessible name is a separate one. The main point here is that we need to be consistent from one SC to the next, and WCAG 2.0 already adopts the convention of using "user interface component" and "name", although I'll admit I'm much more concerned with the latter since we've got two definition for the same thing.

@jake-abma
Copy link
Contributor

We could change the definition just a bit by mentioning they are the same thing, like: name (a.k.a. accessible name). This way we can keep the 2.0 version and also clear up the air for the other one.

@joshueoconnor
Copy link
Contributor

PR for this #377

@DavidMacDonald
Copy link
Contributor

DavidMacDonald commented Oct 5, 2017

I'd like to explore another possible way to reconcile the two. My reason for this is that "Accessible Name" is now the most common term used in industry, rather than "name"

Within our charter, I think we can do the following, simply add the word (accessible name) after the term in the definition. Perhaps Michael can confirm this.

name (accessible name)
text by which software can identify a component within Web content to the user
...

I think it could keep the new SC easier to understand which has value. It seems to lose understandability to those not on our inner circles with just "name".

@mraccess77
Copy link

mraccess77 commented Oct 5, 2017 via email

@johnfoliot
Copy link

johnfoliot commented Oct 5, 2017 via email

@steverep
Copy link
Member Author

This has been resolved by the merge of #377

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

7 participants