Sync Accessible Name SC language with existing WCAG terminology #371
Comments
+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… |
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... |
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. |
@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. |
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. |
PR for this #377 |
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.
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". |
* 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.
+1
Jonathan
|
+1
This is what Jake Abma suggested 2 weeks ago (
#371 (comment)).
JF
…On Thu, Oct 5, 2017 at 3:43 PM, Jonathan Avila ***@***.***> wrote:
* 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.
+1
Jonathan
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#371 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABK-c64oRSyltPNlE8YWTINcZI9apHiFks5spT9cgaJpZM4PPQH->
.
--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com
Advancing the mission of digital accessibility and inclusion
|
This has been resolved by the merge of #377 |
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:
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.
The text was updated successfully, but these errors were encountered: