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 https://github.com/act-rules/act-rules.github.io/issues/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>

[awkawk]

Thinking about this more. As @mraccess77 indicated earlier, it is worth looking at 1.1.1 also:

Controls, Input If non-text content is a control or accepts user input, then it has a name that describes its purpose. (Refer to Success Criterion 4.1.2 for additional requirements for controls and content that accepts user input.)

1.1.1 indicates that the name needs to describe the purpose of the control. 4.1.2 indicates that the name needs to be programmatically determinable. 2.5.3 indicates that the name needs to match the label. 2.4.6 indicates that the label needs to describe the purpose.

So, assuming that these examples are for a button that performs a "close" function: <button aria-label="Open">Close</button> Passes: 4.1.2, 2.4.6 Fails: 1.1.1, 2.5.3

<button aria-label="">Close</button> Passes: 2.4.6 Fails: 4.1.2, 1.1.1, 2.5.3

Typically, I consider the part of 1.1.1 to actually be part of 4.1.2, so if we have a control like the first example, I would file an internal bug against 4.1.2 rather than 1.1.1. That said, a strict reading of the actual language of WCAG 2.x seems to indicate that the actual issue is 1.1.1.

Let's hope we have never have a law that requires 4.1.2 and not 1.1.1!

[patrickhlauke]

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"

not quite, because for software to identify the function (and not "identify it to the user"), it needs to be from a specific set of values.

whereas a name by which software can identify a control can be anything, as long as it's not missing/empty.

[patrickhlauke]

@awkawk i'm not quote sold on the idea of dragging out 1.1.1 for controls. otherwise we can start to use 1.1.1 for anything that isn't just pure text strings (form controls, list structures, ...?)

https://www.w3.org/TR/WCAG21/#dfn-non-text-content

and to be clear, the quote bit there

If non-text content is a control or accepts user input, then it has a name that describes its purpose.

is, in my mind, used here to describe things such as

<button><img src="..." alt="..."></button>

and not to say that controls/input can all be regarded as non-text content (otherwise, THIS interpretation is also nowhere to be found in normative language for 1.1.1 or in the understanding for 1.1.1)

indeed, the understanding for 1.1.1 says

For non-text content that is a control or accepts user input , such as images used as submit buttons, image maps or complex animations, a name is provided to describe the purpose of the non-text content so that the person at least knows what the non-text content is and why it is there.

and not that all sorts of controls are to be treated in light of 1.1.1 when it comes to their name being descriptive/meaningful

[awkawk]

@patrickhlauke darn, I shouldn't write things before caffeine. You're right that 1.1.1 is for the non-text content and impacts controls with non-text content. One could argue that the rectangle that forms a text input or the checkbox square and check are the non-text content, but this isn't really reflected in the understanding document.

So, apart from the small set of controls where that applies, the question is whether 4.1.2 requires correct and programmatically determinable information or just programmatically determinable information.

In a strict reading, I'd say that the fact that 1.1.1 indicates that there needs to be equivalent text makes it challenging to say that the accuracy of the name in 4.1.2 is implied. In 4.1.2 the name is defined as:

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

A common sense reading is that if you identify something to a user that doing so correctly is assumed, but I do see the argument that since we are talking about programmatic identification that we are asking about whether the information is exists and is exposed rather than whether it is correct.

I will still continue to treat incorrect labels as issues, and fortunately this is something that I don't get pushback against.

Related to one other point you made, techniques often go beyond the requirements. Techniques demonstrate ways that are sufficient to meet the SC, not necessarily "minimally sufficient". There are very few "minimally sufficient" techniques as the WG does also want to showcase best practices in techniques.

[JAWS-test]

Which criterion does the following buy button violate?

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

It does not violate the following:

• 1.1.1 (no non-text)
• 2.4.6 (label "buy it" describe topic or purpose)
• 2.5.3 (label is in name)
• 3.3.2 (label "buy it" is provided)
• 1.3.1 (is not conveyed through presentation)
• 4.2.1 (button has a name, even if it's the wrong one)

I would therefore say: The button violates at least 4.1.2.

[patrickhlauke]

I will still continue to treat incorrect labels as issues, and fortunately this is something that I don't get pushback against.

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

[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)