Does SC 2.5.3 fail when there is a visual text label but the control has no accessible name? #2045
Comments
|
oddly, somebody raised this question internally the other day. our consensus was that yes, a control that lacks any kind of accessible name, but where there is visible text that can be interpreted as being the label, this fails both 4.1.2 (for lack of an accname) and 2.5.3 (and, depending on the exact nature of the markup/how it wasn't done correctly, likely 1.3.1). one of those "cascades of fail" situations. |
|
ok, I tend to agree, BUT, when there is no accessible name, from a die hard technical perspective, it is not applicable to 2.5.3 as there is no name. In other words, the moment you have a name it must be present, if there is no name, you fail 4.1.2 and 1.3.1 but not 2.5.3... (there is no "...the name...") |
|
don't think it's worth going down the "the accessible name is there, but it's [edit] and from a technical die hard perspective, it's working out if the string/pattern matching that you're effectively doing fails the SC if the string comparison throws an exception because the accname is |
2.5.3 is applicable because because there is a label. The applicability condition being met, the SC (1) requires a name and (2) requires certain characteristics of the name.
This seems very straightforward to me. But given who asked and who is commenting, my intuition is that I must be missing something! |
|
@bruce-usab the main reason I asked is 1) to make sure we have consensus and 2) the lack of listed failure technique or mention in the understanding document. |
|
@bruce-usab I think we all agree, but strictly reading the SC it demands a name, and if it's there the label must be part of it. My remark was that IF a component lacks an accessible name, is the SC still applicable? It is a resounding YES if NULL is seen as a valid fallback accessible name (so basically it's not possible to NOT have a lack of an accessible name) I'm still not sure if this is the case in the WCAG definition sense, but also maybe not worth the discussion (or is it?) Personally I would not fail a lack of proper accessible name to 2.5.3, but to 4.1.2 / 1.3.1, and also I don't consider null as a fallback. Still wondering how to treat an "empty accessible name" in combination with 2.5.3 after this issue, not convinced yet although we all want to agree on the combination of both for this SC as you mention @bruce-usab (1. name, 2 label included) |
|
@patrickhlauke not sure if I get this right now based on your comment, but I never said / intended to say null is an accessible name, on the contrary, I did say / suggested that the SC doesn't demand an name, only if there is a name the SC is applicable, otherwise not but you fail other SC. |
Yes. The SC is applicable because there is a label. The SC is applicable, and the component fails. It is the same logic we use for images. If there there is an image, then there must a text equivalent. It is the same logic we use for captioning. If there there is a movie (with sound), then there must captioning. I agree that we should craft a failure example. |
but the wording of the SC doesn't say "For user interface component that have a name ..." - so it's not scoped to just user interface components that have a name. the conditional is whether or not they have a label with text/image of text. there's nothing in the normative, nor the non-normative, wording for the SC that suggests that you can "bail out" of the SC is there's no accessible name. |
|
My first thought was that no name means not applicable, but the SC says “ the name contains the text that is presented visually”. Therefore if there is no name, it doesn’t contain the text, therefore fails. Personally, I’d just report it under 4.1.2, with a note that when updating it, it should also meet 2.5.3. |
|
I've been known to write combined "fails 4.1.2, and as a result also fails 2.5.3" bug reports when encountered (in a similar way i'd file combined "fails 1.1.1, and as a result also fails 4.1.2" type issues for things like buttons that only have an image as their content, and that image lacks alt text, and there's nothing else on the button that could give it an accessible name, that sort of thing...again, the classic "cascade of fail (tm)") |
|
Just for the record: we can agree on the requirement for an accessible name for 2.5.3 , but during the development of this SC we never discussed the => 1. an accessible name is required, 2. the label must be part of it. We only discussed: there's a problem when the label doesn't match the name, let's fix it with a SC |
|
(ps. it's also very logic to not require the accessible name in the first place, as there was a SC already for this present in 2.0, and the acceptance requirements for a new SC is that it's not covered already, thus having that discussion being redundant) |
it's perhaps splitting hairs, but: we're not saying (at least i'm not) that the above rationale says "the SC requires that there is an accessible name". the requirement is still as discussed. it's just that if there is NO accessible name, and there is text/image of text that acts as label, then it's an automatic fail of the "is the label text part of the accessible name". a subtle difference. this isn't trying to sneak in a new requirement clause, it's just the logical conclusion of the existing normative text. i.e. this scenario (when there is NO accessible name at all) is just the extreme case/taken to its logical conclusion |
|
a collateral bonus of the SC |
|
Is there an update to make, or are we happy with the agreement in this discussion? (And therefore can we close it.) |
|
Perhaps we could just indicate in the understanding that Add a technique like H44 And then add a failure technique such as F66 to it:https://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20161007/F68 but F68 may need to be updated to communicate that the accessible name needs to include any visible text label in it's accessible name. |
|
yeh, was going to suggest that it'd be nice if an example could be added to https://w3c.github.io/wcag/techniques/failures/F96 For instance, this conversation would cover this failure example: <p>Enter name</p>
<input type=text> |
|
yeah, that's my thinking too. add a clear wording to the understanding (as per @mraccess77 though nitpick "this criterion" (singular) and a failure technique. i can have a go at doing a PR once id24 is over tonight/tomorrow |
|
Proposed PR #2057 |
…ailure technique) (#2057) Also cleans-up 2.5.3 understanding document markup/structure - adds new F111 Control with visible label text but no accname (improperly numbered F109 initially) - add failure technique in Understanding document - added notes in Understanding about UI components with visible text and no name failing both 4.1.2 and 2.5.3 - removed direct reference to WCAG 2.1 - resolved discussion with ACT on where to report some of the failure examples Closes #2045 --------- Co-authored-by: Alastair Campbell Co-authored-by: Mike Gower Co-authored-by: Scott O'Hara Co-authored-by: Dan Bjorge
Would a control that has a visible text label but not an accessible name associated with the control fail SC 2.5.3? I am aware that it would fail other criteria such SC 1.3.1 and 4.1.2. I want to make sure that folks are consistently failing appropriate criteria.
If it's determined that it does fail - should we then link some of the techniques for providing accessible names into the SC understanding document?
The text was updated successfully, but these errors were encountered: