Technique H64 interpreted as 4.1.2 requiring descriptive accessible name?

[patrickhlauke]

The current ACT Rules iframe elements with identical accessible names have equivalent purpose seems to imply that under WCAG 2.1 4.1.2 accessible names must be descriptive/unique. As normatively 4.1.2 doesn't say that, and there's no indication in 4.1.2's understanding documentation about it, I opened act-rules/act-rules.github.io#1008

There, it was pointed out that inspiration was taken from H64 Using the title attribute of the frame and iframe elements.

I would still say that 4.1.2 says nothing specific about the accessible name of an interface component other than the component needs to have one. Whether it's descriptive or not is irrelevant and not defined by the SC (neither normatively in the SC text itself, nor non-normatively in the understanding document). In fact, it's one of those gaps in WCAG (where links need to have link text that makes sense in context (AA) and even out of context (AAA), but no such requirement exists for accessible names under 4.1.2 - though arguably, for controls like <button> elements, you COULD argue that they need to have descriptive labels/accessible names in light of 2.4.6 Headings and Labels).

Can this be clarified?

[mraccess77]

For controls you can fall back on 1.1.1 which in the understanding doc says 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.). But an IFrame may not fit as a control.

[patrickhlauke]

For controls you can fall back on 1.1.1 which in the understanding doc says Controls, Input: If non-text content is a control or accepts user input

but only if the control is non-text-based (i.e. a button using only an image, rather than a button with text) ... as otherwise that'd be stretching that particular definition, no? Otherwise that seems like a very flimsy re-reading of that SC.

and, even in the case of a non-text-based control, it may fail 1.1.1 but not 4.1.2 if it DOES expose an accessible name (regardless of how descriptive of the purpose or not it is)

[mraccess77]

@patrickhlauke I'd consider an input control with a border as not being a text control -- the label being separate -- but you could consider a user interface control to be the label and input combined per the definition of user interface control.

[patrickhlauke]

sorry, but that sounds like a very tenuous stretch of what text and non-text controls are. show a "normal" person (i.e. not somebody who works in standards) a button that uses only text and a border, and ask them "is this a text control or a non-text control", and i'd hazard a guess that most people will say it's a text-based control...

also, in practice, what does that mean for your interpretation? do you continuously flag buttons that just have text saying "Add to cart" or similar as not being descriptive enough and fail them under 1.1.1? seriously?

[JAWS-test]

I think an iFrame is not a user interface component. In my eyes, an iFrame is more of a structuring element such as headings and landmark regions. And that only because it is output as such by AT. Since seeing users can't recognize iFrames either, it would be better if AT ignored iFrames completely. Pages should only be structured with headings and regions and the iFrames should simply not be perceptible.

Furthermore, 4.1.2 is not about the meaningfulness of names at all, but about the fact that a name can be determined by AT.
4.2.1 is part of Chapter 4: "Robust: Content must be robust enough that it can be interpreted by by a wide variety of user agents, including assistive technologies".

When it comes to whether a name is meaningful, you have to search in chapters 3 and 2.4:

• "Navigable: Provide ways to help users navigate, find content, and determine where they are"
• "Understandable: Information and the operation of user interface must be understandable"

Best fits on iFrames SC 2.4.2 "Page Titled", because iFrames are pages that are embedded in other pages.

Otherwise SC 2.4.6 "Headings and Labels" fits as well, because there is no limitation to user interface component.

SC 3.2.4 "Consistent Identification" would also fit, as the criterion indirectly implies that different items have different names.

[JAWS-test]

H64 originates from the dark Middle Ages of HTML. At that time, pages were designed with framesets: a frame for the header, a frame for navigation, a frame for the main content and a frame for the footer or margin column. Today there are regions to structure pages: header, footer, main, nav, etc.

At that time it was important that frames were labeled correctly, because blind users had the possibility to use the frames for navigation (e.g. for SC 2.4.1 "Bypass blocks" - keyboard users without a screen reader probably never helped this).

In HTML 5 frames are obsolete. Only iFrames still exist. The iFrames are hardly used to structure pages, so the output of iFrames by AT is rather annoying. That's why the screenreader JAWS doesn't output frames anymore. It is only possible to display a list of all frames with INS+F9. The frames are no longer output when reading with the arrow keys, with the quick navigation with M or with tab navigation (NVDA continue to output the frames).

Therefore H64 should be abolished.

[awkawk]

There may be something to consider - are iFrames UI components? UI Components are defined as "a part of the content that is perceived by users as a single control for a distinct function". This makes sense for frames in the old way, but doesn't seem to make sense for typical uses of iframes today. Usually, iframes are just a way of dropping in content fragments, whether that is a section of content, or a single advertisement, a collection of advertisements, or other content. For these uses, is there a user benefit to that iframe having a name?

It seems that in these situations users don't have any way to identify the iframe content as distinct from the rest of the page, so for sighted users the perception of the content as a single control for a distinct function doesn't apply and nor does it for non-sighted or other users.

So, I find myself agreeing that modification of H64 should be considered. I think that keeping it for elements is fine but perhaps we either remove or make it advisory for iframes?

[patrickhlauke]

while slightly outside of the original question, more fundamentally: does 4.1.2 put any requirements on components other than they have a name? can you fail a component that has a name that doesn't reflect its purpose/is sufficiently descriptive under 4.1.2? i'd argue that no, 4.1.2 says nothing of the sort. if the name (acting as a label) for a component is not sufficiently descriptive, you'd fail under 2.4.6, NOT 4.1.2 (so EVEN if with some creative reading you could say iframes are kinda-sorta UI components, you'd STILL not be able to fail under 4.1.2 for anything relating to the name beyond "it has a name/doesn't have a name")

[JAWS-test]

does 4.1.2 put any requirements on components other than they have a name?

I'd say yes. SC 4.1.2 is not about the name being meaningful, but about the name being programmatically determinable. I.e. if the visual label of a button is "buy" and the programmatically determinable name is "sell" (e.g. per aria label), then this would be a violation of SC 4.1.2, since the name "buy" cannot be programmatically determinable (it would also be a violation of SC 2.5.3).

[mraccess77]

iFrames might not need names if you consider the whole page one unit with different urls that render as as a single unit. From our definitions: Web unit.
a collection of information, consisting of one or more resources, intended to be rendered together, and identified by a single Uniform Resource Identifier (such as URLs)

I do think there are situations were a name on a iframe would be akin to a named region. So providing a name for an iFrame would be a way to provide a name for a region of the page that was treated as a unit -- e.g. sharing tools, ad frame, embedded credit card form, social media login form, code pen, etc. iFrames can also support scrolling thus making the iFrame itself interactive. So I'd be hesitant to say iFrames no longer need names.

[patrickhlauke]

I'd say yes. SC 4.1.2 is not about the name being meaningful, but about the name being programmatically determinable. I.e. if the visual label of a button is "buy" and the programmatically determinable name is "sell" (e.g. per aria label), then this would be a violation of SC 4.1.2, since the name "buy" cannot be programmatically determinable

i disagree here because what you're talking about is the label, not the name https://www.w3.org/WAI/WCAG21/Understanding/name-role-value.html#dfn-name

and yes, that's the whole reason why 2.5.3 exists. if 4.1.2 already covered this aspect, then 2.5.3 would not have been needed in the first place.

[patrickhlauke]

So I'd be hesitant to say iFrames no longer need names.

so even if we accepted that perhaps iframes do need a name ... does 4.1.2 place any further requirement on that name other than "it needs to be there/be exposed" in your opinion?

[mraccess77]

In regards to SC 1.3.1 and 2.5.3 - we had a discussion many years ago with Gregg V. and he had explained that 1.3.1 required the programmatic label be consistent with the visual label -- but they didn't have to be the same text. With 2.5.3 we tightened that up for speech users to require the visual text to be contained in the programmatic text. So really 4.1.2 is no name, 1.3.1 is about the consistency communicated visually and programmatically and 2.5.3 is about containing the text. 2.4.6 and 3.3.2 are more about visual labels making sense and being present. So there is sort of a hierarchy here of related SC.

[mraccess77]

@patrickhlauke 4.1.2 seems to only require the name be programmatically determined. But there is the definition of name "text by which software can identify a component within Web content to the user" which adds the identify part -- but says nothing about purpose. We do have 2.4.6 but do we need 2.4.4 if we have 2.4.6? Does 2.4.6 imply 2.4.4-like requirements for buttons as well? Just looking at this Github form there submit comment button just says "Comment" -- Does that really communicate the purpose of submitting the comment out of context of the nearby field that isn't programmatically associated? Is association by proximity acceptable? These are all complex questions and we don't really have clear guideance on this. I'd venture a guess that most people don't fail buttons for lack of purpose because they are not inline with text like many links.

[awkawk]

I do think there are situations were a name on a iframe would be akin to a named region. So providing a name for an iFrame would be a way to provide a name for a region of the page that was treated as a unit -- e.g. sharing tools, ad frame, embedded credit card form, social media login form, code pen, etc. iFrames can also support scrolling thus making the iFrame itself interactive. So I'd be hesitant to say iFrames no longer need names.

I agree that sometimes the iframe needs a name, but my point is that isn't a hard and fast "always". Unfortunately to address this would mean changing a common automated testing rule from "check that all iframes have a title attribute or aria-label" to "check all iframes to see if they act as components and then make sure that the iframe has a title attibute or aria-label"

[patrickhlauke]

I agree that sometimes the iframe needs a name, but my point is that isn't a hard and fast "always". Unfortunately to address this would mean changing a common automated testing rule from "check that all iframes have a title attribute or aria-label" to "check all iframes to see if they act as components and then make sure that the iframe has a title attibute or aria-label"

but there's no requirement on what that title/aria-label contains, that it be descriptive, right? and particularly (as tested in that ARC Rules rule iframe elements with identical accessible names have equivalent purpose that it be unique/that same accessible names must serve the exact same purpose?

[patrickhlauke]

so, for the overarching question of what 4.1.2 does and doesn't mandate...

<button aria-label="Open">Close</button>

in my view passes 4.1.2 as it does expose a name that software can use to programmatically present the control to the user; but of course it fails 2.5.3 [edit: originally said 2.4.6 by mistake, confusing even myself now]

<button aria-label="">Close</button>

on the other hand would fail both 2.5.3 [edit: originally said 2.4.6 by mistake] AND 4.1.2, as for the latter it does not expose any name

[awkawk]

@patrickhlauke

I think that you are right for the first example with 4.1.2 but it does pass 2.4.6 since the label is "Close" and that is presumably accurate (although I don't know what the button actually does, so maybe it passes 4.1.2 and fails 2.4.6 :) ) This example definitely fails 2.5.3 Label in Name though.

Similarly, the second example meets 2.4.6 and fails 2.5.3, and depending on accessibility support probably fails 4.1.2 (if browsers ignore null aria-label attributes then the name might default back to the label text, I don't know if this happens or not).

[patrickhlauke]

oh sorry, adding to the confusion here...meant label in name, i.e. 2.5.3, not 2.4.6 [let me edit the previous for clarity, but it seems you're agreeing about the 4.1.2 aspect)

[JAWS-test]

@patrickhlauke

i disagree here because what you're talking about is the label, not the name
and yes, that's the whole reason why 2.5.3 exists. if 4.1.2 already covered this aspect, then 2.5.3 would not have been needed in the first place.

The name definition says: "In many (but not all) cases, the label and the name are the same."
And: "text by which software can identify a component within Web content to the user"

So if name and label contradict each other, then the name is not suitable to identify the element and is therefore according to definition not the name. So this would be a violation of 4.1.2 for me.
4.1.2 does not require name and label to be identical, so I could use synonyms for label and name.

<button aria-label="Purchase">Buy</button>

would be ok according to SC 4.1.2 and 2.4.6, but not for SC 2.5.3.

SC 2.5.3 only exists since WCAG 2.1. It would be absurd to assume that WCAG 2.0 would not have demanded that the name and the label at least match in their meaning.

[patrickhlauke]

The name definition says: "In many (but not all) cases, the label and the name are the same."

That's an observation in the definition, NOT a requirement. Otherwise it would have been worded with SHOULD or MUST.

It would be absurd to assume that WCAG 2.0 would not have demanded that the name and the label at least match in their meaning.

And yet here we are. If WCAG 2.0 didn't have any gaps, there wouldn't have been a need for 2.1. Or, now with 2.1, no need for 2.2.

So, let's stop trying to creatively re-read, re-interpret and "surely what was implied by the founding fathers of WCAG was..." retrospectively justify things that simply aren't normatively (or even informatively) defined.

[JAWS-test]

And yet here we are. If WCAG 2.0 didn't have any gaps, there wouldn't have been a need for 2.1. Or, now with 2.1

The gap of WCAG 2.0 was that name and label could be different ("Purchase" as name, "Buy" as label or "Buy the products" as name and "Buy now the products you selected" as label). SC 2.5.3 prohibits this.

So, let's stop trying to creatively re-read, re-interpret and "surely what was implied by the founding fathers of WCAG was..." retrospectively justify things that simply aren't normatively (or even informatively) defined.

In my eyes, this is exactly what you do with every discussion here. Also the WCAG 2.0 defines name clearly: "text by which software can identify a component within Web content to the user". If I and all the dictionaries I have consulted are not wrong, the English word "identify" means not only to find something, but to describe its meaning or purpose correctly.
If you then look at the techniques for 4.1.2 (e.g. ARIA16: Using aria-labelledby to provide a name for user interface controls), you will see that firstly label and name are used synonymously and secondly that "Check that the text of the referenced element or elements accurately labels the user interface control" is required.
For example, there is also F20 for SC 4.1.2: it is an error if label and name do not match in meaning: "Check each text alternative to see if it is describing content other than the currently-displayed non-text content"

[jake-abma]

As I read it, it's NOT about the descriptiveness, as the text states: "the name and role can be programmatically determined;" Not even the "visible name or label' as this is not mentioned, but the programmatic presence of a name.

[jake-abma]

And my reading of a UIC is NOT applicable for a iframe, what is there to 'control' / what actions is there to undertake, I can't see how this can fit.

user interface component
a part of the content that is perceived by users as a single control for a distinct function

[patrickhlauke]

If you then look at the techniques for 4.1.2

many of the techniques are imperfect and accidentally sneak in more requirements than are actually normatively defined. what counts in the first instance is the normative wording of an SC. the related understanding document for that SC can help clarify some aspects, but can't really introduce new requirements. and right at the bottom of the food chain are techniques...and there, failure techniques are generally more important than positive techniques (as failure techniques must fail all the time, while positive techniques are only "one of many" ways to satisfy an SC).

long story short, having one or two techniques (as that check for descriptiveness/appropriateness of the name is not consistently present the same way in all of the related techniques) bring up a requirement that isn't explicitly there to me points more to incorrect techniques that go beyond what they should, rather than a clarification of what may have been implied in the SC. if an SC requires something, it should really be evident in its normative wording (or at least clearly stated in the understanding document for it).

[JAWS-test]

if an SC requires something, it should really be evident in its normative wording

And so it is: "Name" is defined as "text by which software can identify a component within Web content to the user"

[patrickhlauke]

and if it's "identify" in terms of providing an identifier, that identifier does not necessarily need to be descriptive (similar to the concept of an id which provides an identifier, but does not need to be descriptive or anything else...just that it needs to exist).

[JAWS-test]

that identifier does not necessarily need to be descriptive

Then we have reached the point where in SC 4.2.1 it does not matter which ARIA role I assign to an element, because the definition of role is analogous to the definition of name:

"text or number by which software can identify the function of a component within Web content"

Would you say that according to SC 4.1.2 a checkbox with the following code is correctly marked?

<span tabindex=0 role=cb></span>

or

<img tabindex=0 aria-roledescription=c1>

[patrickhlauke]

Which criterion does the following buy button violate?

not everything that's wrong/broken violates an SC. this is the sort of thing we'd still note in audits, but as a best practice rather than a hard failure.

[awkawk]

however, that's a source of problems and inconsistencies if some auditors do it one way, and others do it another way...

I agree... mostly. :) Let me ask you - if you encounter a
<button aria-label="cancel">Submit</button>
and you were reporting against 2.0 AA, would you not log an issue?

[patrickhlauke]

see above: would flag it as a best practice issue, with wording along the lines of "while nominally this passes 4.1.2, as the control does provide an accessible name, the name it exposes is incorrect and will mislead assistive technology users" (and yes, this will fail 2.5.3 anyway, so mention it there too as part of the actual failure).

[edit: in addition, would likely mention this under 3.3.2 labels or instructions, but there it's not a fail either since it's not presented to all users and thus falls outside of the definition of "label" ]

[mraccess77]

Regarding div tabindex=0 role=button aria-label="Do not buy it!">buy it div

I might fail 1.3.1 as this programmatic label is not consistent with the visual label. The information and and relationship communicated visually is not available programmatically -- although it is in text that text is overwritten in a way that not is not accessibility supported. If the visual label and programmatic label are not consistent then I see it as a 1.3.1 issue.

[patrickhlauke]

@mraccess77 an interesting take there with 1.3.1. seems for that particular case, this is indeed a good candidate to file against.

now, wondering if any of this can/should be documented anywhere... will have a think about potential notes for understanding somewhere...

[JAWS-test]

now, wondering if any of this can/should be documented anywhere...

If we agree that the criteria apply as follows

• 1.3.1: name is consistent with label [was wrong: meaningful name]
• 2.5.3: Label in Name
• 3.2.4: Consistent label for same functionality
• 2.4.6: meaningful label
• 2.4.4: meaningful link text or link context (label and name)
• 2.4.9: meaningful link text (label and name)
• 3.3.2: label is available (only for form fields with user input), content does not matter
• 4.2.1: correct role and correct status (not in text form, but in programmatically determinable form, i.e. aria-roledescription is not sufficient)
• 4.2.1: Name can be determined programmatically, content does not matter

I'd like it if that was added to the understandings.

I would also like to remove H64 because iFrames are not interactive elements, iFrames are not self-developed elements ("4.1.2: ... This success criterion is primarily for Web authors who develop or script their own user interface components. For example, standard HTML controls already meet this success criterion when used according to specification"), and iFrames don't have relevant semantics, i.e. should be treated more like a div element. If H64 is to be kept, I would be in favor of assigning it to SC 2.4.2 "Page Titled".

[mraccess77]

Hi @JAWS-test 1.3.1 does not require the text or accessible name be meaningful -- but instead that the programmatic name is consistent with the visually communicated information. So in the example of the button the programmatic name is not consistent which the visual label and fails 1.3.1. But in other cases where you have a different situation the outcome would be different and you might pass 1.3.1 because the name is consistent with the visual even if they are not meaningful.

[JAWS-test]

Hi @mraccess77, thank you for pointing that out. I have corrected it in the list above

[WilcoFiers]

Throwing in my 2p.

Are iframe titles required under 4.1.2?

Yes, in most cases. David has a very good write-up on this. I fully agree with him on this.

source: http://www.davidmacd.com/blog/is-title-attribute-on-iframe-required-by-wcag.html

A title is not required if content in iframe is not distinct from surrounding content and has no tab stops inside it, and the author adds tabindex="-1" on iframe so it doesn't receive tab focus.

Is a meaningful name required for 4.1.2?

Yes, absolutely. The requirement for what a name needs to be is in the definition of "name" in WCAG:

source: https://www.w3.org/TR/WCAG21/#dfn-name

text by which software can identify a component within Web content to the user

In other words, if the user can't identify the component based on what software tells them about it, that "text" is not a "name". The name has to be identifying, if it isn't, it's not a real name.

The same logic applied to "role", "state" and "value". SC 4.1.2 doesn't just require that it has those properties, but that those properties are correct. A button that's marked up with role="heading" is a failure of 4.1.2, because the semantic role of the element isn't the actual role of the component.

[awkawk]

@WilcoFiers I don't understand why the lack of tab stops makes any difference.

Is the iframe a component? How is the content of an iframe any different to a user than the content of a div? Sometimes it will be but sometimes it is just the way that content is added to a page...

[mraccess77]

Hidden iframes or those with width/height 0 would not need a name as they are not rendered to users including users of assistive technology.

[patrickhlauke]

Is a meaningful name required for 4.1.2?
Yes, absolutely. The requirement for what a name needs to be is in the definition of "name" in WCAG:

source: https://www.w3.org/TR/WCAG21/#dfn-name

text by which software can identify a component within Web content to the user

In other words, if the user can't identify the component based on what software tells them about it, that "text" is not a "name". The name has to be identifying, if it isn't, it's not a real name.

The requirement is that it has a name that the software can use to identify the control, not that the user needs to be able to identify what the component is. As members of the WG here have a split opinion, it's not quite cut and dry here if that also means it needs to be meaningful enough to be unique/accurate/descriptive/etc.

I understand the "identify" as merely the difference between the software saying "there's a button" versus "there's a button with a name of 'chicken'". whether or not that name is descriptive, or unique, or any other restriction placed on it, is not normatively required IMO (otherwise it should have been explicitly required, rather than somehow implied)

[patrickhlauke]

The same logic applied to "role", "state" and "value". SC 4.1.2 doesn't just require that it has those properties, but that those properties are correct.

but there's a difference here. with role/state/value, there's always a very clear "correct" one. whereas with name, who's to say what the "correct" name for a control is? that's subjective, whereas role and state are quite objective. (yes, you could argue that it's "common sense", but that doesn't wash normatively ... and to me, not strong enough to then be codified into an automated pass/fail test)

[JAWS-test]

For detailed test results see: iframe with title attribute Screen reader compatibility

and WebAim says:

iFrames: Unlike frames, a descriptive title attribute value is not necessary for accessibility. If the inline frame presents content as a whole that is visually distinctive, such as an advertisement or video player, then a title should be provided to indicate this distinction

[WilcoFiers]

but there's a difference here. with role/state/value, there's always a very clear "correct" one. whereas with name, who's to say what the "correct" name for a control is? that's subjective, whereas role and state are quite objective. (yes, you could argue that it's "common sense", but that doesn't wash normatively ... and to me, not strong enough to then be codified into an automated pass/fail test)

I don't think determining if the role is appropriate is objective either. Given the endless "is it a link or a button" discussion we've had in our industry, that doesn't seem to be the case. Perhaps there is a difference, but whatever difference that is, the SC text doesn't mention it. I don't think the argument that roles have to be correct, but the name doesn't is a particularly compelling one. But maybe others do think that, I don't really know.

I think the way to find out is to get this rule to AG and have them either confirm it or reject it.

[patrickhlauke]

Given the endless "is it a link or a button" discussion we've had in our industry

not sure this "endless discussion" is happening in our industry (of accessibility-savvy people), but more in the "clueless developer" circles. which is not an argument for/against the interpretation to take as an auditor/a11y engineer...

but fair enough, submit to AG as a whole (noting though that many AG folks have commented here, including me as a part-timer AG member) ... as long as that particular aspect is highlighted as part of the submission (since, as we keep finding out even for WCAG, things slip through / have unintended side effects / wordings that aren't always immediately obvious to AG when things get written/reviewed/approved)

[awkawk]

I think the way to find out is to get this rule to AG and have them either confirm it or reject it.

@WilcoFiers do you know when the WG will be reviewing the proposed test?

[mraccess77]

A related topic is whether pages inside the iFrame need a title element - I'd say no as the iframe is an embedded part of the page and WCAG's conformance unit does is not designed for embedded content on it's own but pages that may include embedded content.

[yatil]

Hi, can we get a decision on this?

[patrickhlauke]

Hi, can we get a decision on this?

added this to the WCAG 2.x backlog for discussion. can't guarantee that we will, but we'll see...

[yatil]

I mean, even a decision like “this cannot be determined/we leave it to testers” is a decision that I can live with. I have a hard time with questions that are left hanging for a number of years.

[detlevhfischer]

I happened to come across this old issue, saw that there have been requests to resolve this in the AGWG, and in order to move on with it, I have proposed a Working Group answer that reflects the view of a part of the Working Group while not satisfying another part. Nevertheless, it seems important to clarify the normative ask of 4.1.2, which in the end hinges of the understanding of the definition of "name": what it means to "identify a component within Web content to the user" (my emphasis).

Proposed working group answer:
The Working Group has been asked to determine whether the normative text of Success Criterion 4.1.2 "Name, Role, Value" implies that an accessible name must not only be present but also descriptive/unique.

This answer brackets out the question whether an accessible name has to be unique, since this seems orthogonal to the question of whether it needs to be not only present (non-empty) but also in some way descriptive.

The issue discussion has shown that there are different positions within the WG on the meaning of the normative text in the light of the the normative definition of name. While the normative text of 4.1.2 "Name, Role, Value" requires that for user interface components

the name and role can be programmatically determined

The normative definition of name is

text by which software can identify a component within Web content to the user

"to the user" indicates that this identification via programmatic determination is not merely one that can be used by some program logic, but that the name can be understood by a user when it is exposed, for example, via a screen reader. If a button with a visible label of "buy now" had a programmatic label of "cancel", the accessible name is misleading, i.e., from a user perspective, the name does not identify the component.

In 4.1.2, there is no requirement that the visual label of a control is identical to (or contained in) the accessible name (this is is the ask of 2.5.3), and if both deviate while identifying the control to the user, that is no failure of 4.1.2. The name for a button initiating a purchase may thus equally be "Buy", "Buy now" or "Purchase now", since all three names would identify the component to the user. If, however, the accessible name of that button would be some code meaningless for the user, such as "F923401", or something that clearly contradicts the function of the User Interface Component, such as "Cancel", it would fail 4.1.2.