Wcag: Can text buttons fail 1.1.1 and 3.3.2?
This came up during the the ACT TF call this week. We were looking at a rule that checks if buttons have an accessible name. It was clear buttons are tested under 4.1.2, but the group seemed split about whether or not 1.1.1 and/or 3.3.2 can fail for something like this:
<button type="button" />
1.1.1 Non-text content
For 1.1.1 the argument was that buttons may be considered non-text content. They may contain text, but aren't themselves text. They can also be considered "Controls, Input". Technique H44 suggests that things such as select, textarea and text input are non-text content. On the other hand, the understanding document mentions this:
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.
While it doesn't outright say buttons without images don't apply, that it mentions images / animation in all three example suggests that might be the intention. The ACT Task Force would like to know what the position of the AGWG. Are buttons without images still considered non-text content? And perhaps in extension to this, should form fields be considered non-text content?
3.3.2 Labels or Instructions
For the same button, would the lack of a visible label be considered a failure of 3.3.2? Since there is no definition for "requires user input". Clicking a button is (usually) required for user input to be submitted, however (usually) buttons themselves aren't used as a mechanism for the user to provide information.
Either way it would be helpful to include information about how 3.3.2 relates to buttons in the understanding document.
WilcoFiers
All 36 comments
I will say that a label can be an icon and 3.3.2 applies to visual labels (icons, text, or even another control that acts as a label). So the situation you are talking about is a button with no visual label text or icon or other associated control - this seems like an issue for all users.
In regards to whether 1.1.1 applies to the non-text portion of things like buttons and input fields -- I asked a similar question in #929 https://github.com/w3c/wcag/issues/929
mraccess77
on 5 Dec 2019
My interpretation of 1.1.1 is that for controls 4.1.2 handles the requirement for a name. We should look at H44 to make that more clear. 4.1.2 handles the "what kind of thing is this and what is it called?" questions and I don't think that 1.1.1 has anything to do. I wish 1.1.1 said "If non-text content is a control or accepts user input, refer to Success Criterion 4.1.2 for additional requirements for controls and content that accepts user input." as this would be more clear.
For 3.3.2, if you have a button with no text and no image with a text equivalent, it lacks a label and would fail. If a User agent automatically adds text to the button then that is the label.
I'll think about it more, but that's my off-the-cuff response
awkawk
on 5 Dec 2019
purely thinking about the specific case here of <button type="submit"></button> ... browsers will show this simply as a completely empty button. there is no text there (as opposed to <input type="submit"> where browsers will add a generic "Submit" text). but also, there is no image or anything else that conveys any meaning/content, so I can't see how this would fail 1.1.1 ... it's a mystifying unlabelled button for all users.
For 3.3.2, if you have a button with no text and no image with a text equivalent, it lacks a label and would fail. If a User agent automatically adds text to the button then that is the label.
but 3.3.2 specifically says "when content requires user input". a button doesn't require user input...it either gets activated or not. the user doesn't enter any input (unless we stretch the definition and say that an activation is a form of input). we could also split hairs over the "required" bit ... what if a field is optional? in short, the normative wording for 3.3.2 may be a bit unfortunate...
patrickhlauke
on 5 Dec 2019
IF the WG agrees/feels that activating a control is also a form of input, this should probably be clarified in the understanding document at least (which currently only seems to focus on examples involving text inputs where a user actively enters/types in information). maybe something along the lines of
While the normative wording of content that "requires user input" may suggest required text input fields, it is intended to be much broader and cover any form of content that allows for user interaction.
it would be nice if the normative text could be tweaked to change "requires user input" to something more generic like "allows user input or interaction", but alas this opens the whole discussion about immutability of SC normative wording again...
patrickhlauke
on 5 Dec 2019
I couldn't help but plonk that example into a test page.
I don't think it fails 1.1.1 as there is no "text alternative that serves an equivelent purpose", because there is no meaningful visual content presented to any user. (Unless I've misunderstood the premise?)
It would fail 3.3.2 if there are no instructions above, but the addition of instructions above it would pass the wording of the SC. As a submit button, I am assuming it is being use to submit, therefore the "content requires user input" even if that field isn't the one with the input in it.
I think it does fail 4.1.2 as there is no programatic name.
alastc
on 5 Dec 2019
but also, there is no image or anything else that conveys any meaning/content, so I can't see how this would fail 1.1.1
addendum: unless there's something else, like a CSS background image, that is used to visually denote that button, of course
patrickhlauke
on 5 Dec 2019
I think the confusion is in the variation between the SC and the Understanding paragraphs
SC
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.)
Understanding:
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.
I think given the Understanding clarification, we need to assume that we wouldn't fail a missing label in 1.1.1 unless its an image based control.
I'd also go with 4.1.2, (in fact I almost never fail controls under 1.1.1, when 4.1.2 catches it more explicitly and 1.1.1 says look at 4.1.2 for additional requirements)
DavidMacDonald
on 5 Dec 2019
I don't disagree that maybe 1.1.1 could be written better. But RAW (rule as written), the first bullet reads:
If non-text content is a control or accepts user input, then it has a name that describes its purpose.
A button (text or image, makes no difference) fits that perfectly. I think we have to say that 1.1.1 applies.
And perhaps in extension to this, should form fields be considered non-text content?
Yes, for the same reason. As a reminder, the WCAG definition for non-text content is expansive:
any content that is not a sequence of characters that can be programmatically determined or where the sequence is not expressing something in human language
Is it a problem if a single element fails two (or three) SC?
I also don't think it is a problem for a button (with a good name, but not clear label or instructions) to pass 1.1.1 (and 4.1.2) but fail against 3.3.2.
For the same button, would the lack of a visible label be considered a failure of 3.3.2?
Yes, but note that the phrasing of 3.3.2 provides for wide latitude as to the placement of the label.
Since there is no definition for "requires user input".
And I would hope that we do not need to write such a definition! Buttons (and form fields) are obviously a mechanism for user input.
bruce-usab
on 5 Dec 2019
the first bullet reads:
But the bullets are the exceptions, I'd argue the first line of 1.1.1 isn't applicable therefore the exceptions don't matter (in this scenario). No content is shown to anyone, so there isn't an equivelent purpose to be put in an alt text.
Is it a problem if a single element fails two (or three) SC?
I think we've tried to avoid that before (and it's in the 2.1/2.2 requirements), and it does make reporting in audits harder if you repeat things or have to cross reference a lot. Not a big thing to me, but it can cause more confusion for people not as familiar with the guidelines.
alastc
on 5 Dec 2019
The 2.1/2.2 requirement is that _new_ SC not be duplicative. Part of that, of course, is because the _old_ SC overlap more than we might like!
the first line of 1.1.1 isn't applicable
I agree iff no content is being shown to anyone, but that is not the case here. @patrickhlauke mentions that:
browsers will show this simply as a completely empty button
Same as with your test page.
@patrickhlauke goes on to make the argument that clicking a button is not user input. I disagree with that analysis, as we were not trying to be that pedantic when writing 2.0!
bruce-usab
on 5 Dec 2019
@kengdoj points out to me that code like <button type="submit" /> _is_ “a sequence of characters that can be programmatically determined” and therefore is _not_ “non-text content”.
I remember that caveat being there so that 1.1.1 is not requiring alt text for elements like P and H1. Is non-text content much more narrow than I think? Do we have an Understanding doc just for our defined terms? If not, do we need that? For the most part, I think we pretty well address defined terms in the context of Understanding SC. OTOH, “a sequence of characters that can be programmatically determined” being text (because it is not non-text) is making my brain hurt!
bruce-usab
on 5 Dec 2019
@kengdoj points out to me that code like quote unquote is “a sequence of characters that can be programmatically determined” and therefore is not “non-text content”.
That text isn't presented to the users.
awkawk
on 5 Dec 2019
@awkawk do you regard buttons and fields as being "non-text content"?
bruce-usab
on 5 Dec 2019
@bruce-usab Are they text? Are they content?
awkawk
on 5 Dec 2019
Button/fields are content. They are not text. I had presumed (until about an hour ago) that they were _obviously_ non-text content. But now I am not so sure!
bruce-usab
on 5 Dec 2019
@bruce-usab I did a similar thing. In practice, a control that is missing an accessible name is marked as a 4.1.2 issue and not as a 1.1.1 issue when we conduct an audit, but it is hard to argue that that issue doesn't also fail 1.1.1.
Does it matter if it is a 4.1.2 issue or an issue on both? Not really. I think that it confuses engineers who are trying to fix it since now they may need to understand why it fails both instead of understanding 4.1.2 and fixing it.
awkawk
on 5 Dec 2019
For 3.3.2, I agree that the argument hinges on whether a button is "user input. In practice, I don't worry about this because I haven't seen buttons that lack any form of label, and those that do would be equally inaccessible to all users.
awkawk
on 5 Dec 2019
@bruce-usab
@patrickhlauke goes on to make the argument that clicking a button is not user input. I disagree with that analysis, as we were not trying to be that pedantic when writing 2.0!
then the understanding for 3.3.2 should make that clear. as currently, it only seems to hint at text inputs and such (and RAW (rule as written) can be very narrowly interpreted without any further clarification).
@awkawk
Does it matter if it is a 4.1.2 issue or an issue on both? Not really.
well, it does for consistency's sake. if one auditor notes that your page has X errors, and another notes that your page has Y errors, you want to get to the bottom of that inconsistency. in general, I would suggest failing something for any SCs it fails. while this particular example may be an edge case, it's important to clearly be able to say if an SC applies or not in that particular case.
if it were something like
<button type="submit"><img src="..."></button>
i'd fail the <img> under 1.1.1 for lacking a text alternative, which then leads the <button> to fail under 4.1.2 as it lacks any other means that would provide an accessible name.
similarly, if it were a link
<a href="..."><img src="..."></a>
i'd fail the <img> under 1.1.1, leading to the link failing 4.1.2 for lack of accessible name, and also fail under 2.4.4 and 2.4.9 because the link has no actual link text.
in the case here
<button type="submit" />
though, i'd say there is nothing - no text, no non-text - inside that button. all users will experience this as a generic empty button (sighted users will see it, and non-sighted users will have their AT announce it as a generic "button", so from that point of view the button itself is non-visually conveyed appropriately). so i wouldn't fail this under 1.1.1. I would fail it under 4.1.2 for lack of accessible name.
now the open question, as said, is whether or not those three cases would also fail 3.3.2. as currently written, 3.3.2 seems to only apply to inputs where a user needs to enter information. i'll assume that it also intends to apply to things where a user makes a selection, like <select>, or groups of radio buttons, or checkboxes - though strictly the normative SC language could potentially be read very pedantically to question whether it's an input there or not.
now, does activating a button (to trigger an in-page action, like opening a modal dialog or menu, or to submit a form) count as an "input"? and if yes, does activating a link also count as an "input"? this becomes a can of worms, as suddenly 3.3.2 may actually apply to links and cover the same/similar ground to 2.4.4/2.4.9...
patrickhlauke
on 5 Dec 2019
For some context, back when WCAG 2 was being finalized 2006 to 2008 we did
not have anywhere near as many semantic interactive HTML elements (such as
video, dialog, menu, etc - that became mapped to AAPIs), nor as much
scripting, as we do today. It was much easier to distinguish between text,
non-text, static and interactive content.
We weren't as lame as this conversation might suggest...:-)
On Thu, Dec 5, 2019, 5:15 PM Patrick H. Lauke notifications@github.com
wrote:
@bruce-usab https://github.com/bruce-usab
@patrickhlauke https://github.com/patrickhlauke goes on to make the
argument that clicking a button is not user input. I disagree with that
analysis, as we were not trying to be that pedantic when writing 2.0!then the understanding for 3.3.2 should make that clear. as currently, it
only seems to hint at text inputs and such (and RAW (rule as written) can
be very narrowly interpreted without any further clarification).@awkawk https://github.com/awkawk
Does it matter if it is a 4.1.2 issue or an issue on both? Not really.
well, it does for consistency's sake. if one auditor notes that your page
has X errors, and another notes that your page has Y errors, you want to
get to the bottom of that inconsistency. in general, I would suggest
failing something for any SCs it fails. while this particular example may
be an edge case, it's important to clearly be able to say if an SC applies
or not in that particular case.if it were something like
i'd fail the
under 1.1.1 for lacking a text alternative, which then
leads thesimilarly, if it were a link
i'd fail the
under 1.1.1, leading to the link failing 4.1.2 for
lack of accessible name, and also fail under 2.4.4 and 2.4.9 because the
link has no actual link text.in the case here
though, i'd say there is nothing - no text, no non-text - inside that
button. all users will experience this as a generic empty button (sighted
users will see it, and non-sighted users will have their AT announce it as
a generic "button", so from that point of view the button itself is
non-visually conveyed appropriately). so i wouldn't fail this under 1.1.1.
I would fail it under 4.1.2 for lack of accessible name.now the open question, as said, is whether or not those three cases would
also fail 3.3.2. as currently written, 3.3.2 seems to only apply to inputs
where a user needs to enter information. i'll assume that it also intends
to apply to things where a user makes a selection, likenow, does activating a button (to trigger an in-page action, like opening
a modal dialog or menu, or to submit a form) count as an "input"? and if
yes, does activating a link also count as an "input"? this becomes a can of
worms, as suddenly 3.3.2 may actually apply to links and cover the
same/similar ground to 2.4.4/2.4.9...—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/w3c/wcag/issues/985?email_source=notifications&email_token=ABL6VSR3G3QGUPDMH2JZCDTQXF4O3A5CNFSM4JV3JAYKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGCKYMY#issuecomment-562342963,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABL6VSTXIDGXDAJHPNIJIB3QXF4O3ANCNFSM4JV3JAYA
.
Ryladog
on 6 Dec 2019
@Ryladog you had links and buttons. can we start with those? :)
patrickhlauke
on 6 Dec 2019
Buttons fell under Inputs and Controls of 1.1.1 and therefore fell under
4.1.2 because buttons were mapped to the AAPIs.
On Thu, Dec 5, 2019, 6:56 PM Patrick H. Lauke notifications@github.com
wrote:
@Ryladog https://github.com/Ryladog you had links and buttons. can we
start with those? :)—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/w3c/wcag/issues/985?email_source=notifications&email_token=ABL6VST45BCLSGWKQGZI2R3QXGIJDA5CNFSM4JV3JAYKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGCRVOA#issuecomment-562371256,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABL6VSQMSXRDVM324KLPC6LQXGIJDANCNFSM4JV3JAYA
.
Ryladog
on 6 Dec 2019
I don't think 1.1.1 is that problematic/controversial.
my reading of that first bullet "Controls, Input" doesn't necessarily mean that an image-based control is exempt from 1.1.1, but that its alternative is the name that described the purpose of the input, and that in addition to 1.1.1 it's also subject to 4.1.2 which has additional requirements for controls/inputs. this is also reinforced by the fact that the understanding for 3.3.2 does include examples/techniques specifically covering inputs/controls, so 1.1.1 is applicable to those cases https://www.w3.org/WAI/WCAG21/Understanding/non-text-content.html
the trickier question is: do buttons (and links) fall under 3.3.2. and if they do, do we need to update/expand the understanding doc to mention this fact more explicitly, since that's causing disagreement/confusion.
patrickhlauke
on 6 Dec 2019
Wilco,
For your example button, and for test tools purposes I would say it could
fail, as secondary SCs for 1.1.1 and possibly 3.3.2.
Generally, I identify a primary SC fail, and if applicable secondary or
tertiary SCs, if it matters to the organization. But unless it is a
1.3.1/4.1.2 issue it seems (for non-tool generated reports), it just
confuses implementers.
On Thu, Dec 5, 2019, 7:09 PM Katie Haritos-Shea ryladog@gmail.com wrote:
Buttons fell under Inputs and Controls of 1.1.1 and therefore fell under
4.1.2 because buttons were mapped to the AAPIs.On Thu, Dec 5, 2019, 6:56 PM Patrick H. Lauke notifications@github.com
wrote:@Ryladog https://github.com/Ryladog you had links and buttons. can we
start with those? :)—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/w3c/wcag/issues/985?email_source=notifications&email_token=ABL6VST45BCLSGWKQGZI2R3QXGIJDA5CNFSM4JV3JAYKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGCRVOA#issuecomment-562371256,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABL6VSQMSXRDVM324KLPC6LQXGIJDANCNFSM4JV3JAYA
.
Ryladog
on 6 Dec 2019
The Failures and Techniques often link to many SCs to which they refer. I find this problematic for the test process. It would be better to write the Failures and Techniques in a way that they only refer to one SC at a time (and in case of doubt to make several Failures or Techniques out of one Failure or Technique). I think this is important for the WCAG test and for reporting to customers and developers. Otherwise it becomes inconsistent.
For example, I would never rate graphical buttons and links at 1.1.1 because they are exempt at 1.1.1. I would rate them at 4.1.2 if they didn't have a programmatically identifiable label. If they don't have a visual label, I would rate it 3.3.2 (buttons) or 2.4.4+2.4.9 (links). If the visual label is not meaningful, I would rate it 2.4.6.
If there is neither a programmatic nor a visual label (as in the initial example) the question would be whether it is a violation of the WCAG at all, because this button is unusable for all users.
See: https://github.com/w3c/wcag/issues/929#issuecomment-552083038
JAWS-test
on 6 Dec 2019
I would never rate graphical buttons and links at 1.1.1 because they are exempt at 1.1.1.
I don't think they're exempt. The first bullet clarifies that they provide the accessible name for the control, and that 4.1.2 has additional requirements. This is in addition to 1.1.1. At least that's my reading.
patrickhlauke
on 6 Dec 2019
I don't think they're exempt. The first bullet clarifies that they provide the accessible name for the control, and that 4.1.2 has additional requirements. This is in addition to 1.1.1. At least that's my reading.
Yes, your a right. But:
For me 1.1.1 is clear: Graphical controls do not need an alternative text, but a name. The name is required for both 1.1.1 and 4.1.2. Here one can agree whether it is evaluated only with 1.1.1 or only with 4.1.2 or with both. I am in favour of opting for only one SC. And I would prefer 4.1.2 so that all controls (whether graphical or not) are evaluated with one SC.
The reference ("Refer to Guideline 4.1 for additional requirements for controls and content that accepts user input.") refers to other requirements for controls in 4.1.2 (i.e. role and value and that these can be set by AT).
The question would be whether it is important for AT to recognize that a control is a graphical control.
<button aria-label="Submit"><img alt="" ...></button>: AT would output this as text button (without reference to graphic)<button><img alt="Submit" ...></button>: AT would output this as graphic button (with reference to graphic)
In my understanding, both variants are ok, but I would prefer the first one, because the reference to the graphic in this context is not important and leads to an additional output.
JAWS-test
on 6 Dec 2019
the trickier question is: do buttons (and links) fall under 3.3.2. and if they do, do we need to update/expand the understanding doc to mention this fact more explicitly, since that's causing disagreement/confusion.
My reading of 3.3.2 (inc understanding doc) was that it applies to _forms_ which take user input.
From reading the first sentence I'd have only thought inputs / selects / radio/checkboxs, but the last sentence in the intent is: "this Success Criterion requires that controls and inputs have labels".
I had assumed that a button would only be in scope when associated with data-entry of some sort, i.e. a submit button for a form.
I did not think it applied to links or 'functional' buttons that are unrelated to data entry.
Does that match other people's assumptions?
If not, and given all the other explicit statements about what 3.3.2 doesn't cover, I'd suggest tweaking the last paragraph to something like:
"While this Success Criterion requires that controls and inputs _for data entry_ have labels, whether or not these labels are sufficiently clear or descriptive is covered separately by 2.4.6: Headings and Labels."
alastc
on 6 Dec 2019
@alastc possibly even "data entry and submission" to cover submit type buttons too, otherwise it once again leaves ambiguity about submit buttons that don't explicitly allow data _entry_ as such.
and maybe even adding a very explicit note/sentence that says very clearly and unambiguously "This Success Criterion does not apply to links or other controls (such as controls for disclosure widgets or similar interactive components) that are not associated with data entry or submission"
patrickhlauke
on 6 Dec 2019
One (possible) contradiction (with my own thinking) that this conversation has raised for me is that I still firmly consider buttons to be “input” whereas hyperlinks clearly are not. Yet, what is the difference really? And CSS can be used to make links visually present as buttons!
the last sentence in the intent is: "this Success Criterion requires that controls and inputs have labels".
That overstates requirement of the SC. I agree with you that an edit is in order!
I did not think it applied to links or 'functional' buttons that are unrelated to data entry.
Does that match other people's assumptions?
I have always assumed that 3.3.2 applies to page widgets like search and change-style buttons. They are content that requires user input. For buttons associated with such simple functionality, meeting 4.1.2 and 3.3.2 with the same code is trivial.
I do not think 3.3.2 applies to links.
I like @patrickhlauke idea of adding a Note to 3.3.2. If myself and others have been over-applying 3.3.2 all these years, I think that is okay.
bruce-usab
on 6 Dec 2019
@bruce-usab To add to your thinking, it is worth noting that the HTML spec has different types for the input element, including type="button".
The way that 3.3.2 is defined, I don't believe that it actually applies to very many issues on the web. To pass 3.3.2 all that you need is a visual label for a control, and there are very few cases where this comes up at all. If this applied to links (which it shouldn't IMO) you would need to work hard to fail it and only extreme edge cases would fail. I do think that it is reasonable to treat 3.3.2 as user input controls and to regard standard form control types as covered. A set of radio buttons, a select element, a toggle button pair, a slider are all potentially accepting user input, not just text input elements.
Also, I notice that the sufficient techniques for 3.3.2 associated with G131 lists three ARIA techniques that are associated with it, and I think that this is an error as ARIA techniques here only impact the programmatic name and that isn't required for 3.3.2.
awkawk
on 6 Dec 2019
@awkawk -- I think we are pretty much in rabid agreement. I would characterize 3.3.2 being applicable pretty often, but being trivial to pass. But I think that is what you mean by it not applying to very many _issues on the web_. We agree that conformance with 3.3.2 is mostly not an issue.
I am still hoping someone will jog my memory/understanding about what the definition for non-text content is carving out with “not a sequence of characters that can be programmatically determined”.
I really want to be able to continue rationalizing that (web) content is neatly either text or non-text.
bruce-usab
on 6 Dec 2019
@bruce-usab perhaps the non-text content definition is trying to carve out things like blank buttons? I.e. a button with no text or image content might have a default presentation in the browser, but it can be programmatically determined, so isn't non-text content?
There is possibly a third category: text content, non-text content, and containers?
alastc
on 6 Dec 2019
@alastc certainly the intent was not about _blank_ buttons, but I really don’t know what it was for.
There might be three categories of content: text content, non-text content, and content that is not text and not non-text.
bruce-usab
on 6 Dec 2019
I wouldn't consider a button without a visual label as non-text content. Other form elements are not non-text content either. A button can be labelled with non-text content. Only then is it considered at 1.1.1 (first exception of SC 1.1.1: "Controls, Input").
Just as a container on a page is not non-text content, but represents a page structure that is evaluated at SC 1.3.1. The container therefore does not require a text alternative, but must be semantically correctly marked (e.g. with a landmark region).
JAWS-test
on 7 Dec 2019
Thanks for all the conversation everyone. I appreciate it. It sounds like AG is as split on this as the ACT task force was last week.
I don't think we're going to find an answer or argument that everyone will be convinced by. It seems to me like we're just going to have to pick a solution and ask everyone to adjust their approach accordingly. The ACT-Rules community group has approached it this way:
- Accessible names of
input[type=image]is tested under 1.1.1 and 4.1.2 - Accessible names of all other buttons are tested under 4.1.2 only
Is there anyone who could not accept this as a solution that AG can publish? I'm happy to take any counter proposals back to the CG as well. I don't feel strongly about this. I'd just like us to have a single answer.
WilcoFiers
on 10 Dec 2019
@alastc possibly even "data entry and submission" to cover submit type buttons too, otherwise it once again leaves ambiguity about submit buttons that don't explicitly allow data _entry_ as such.
and maybe even adding a very explicit note/sentence that says very clearly and unambiguously "This Success Criterion does _not_ apply to links or other controls (such as controls for disclosure widgets or similar interactive components) that are not associated with data entry or submission"
based on this and your previous comment, I've made a stab here at expanding the understanding doc https://github.com/w3c/wcag/pull/1568
patrickhlauke
on 26 Dec 2020
Related issues
yatil
·
6Comments
camusamta
·
9Comments
detlevhfischer
·
4Comments
patrickhlauke
·
10Comments
smhigley
·
3Comments
Most helpful comment
@bruce-usab
then the understanding for 3.3.2 should make that clear. as currently, it only seems to hint at text inputs and such (and RAW (rule as written) can be very narrowly interpreted without any further clarification).
@awkawk
well, it does for consistency's sake. if one auditor notes that your page has X errors, and another notes that your page has Y errors, you want to get to the bottom of that inconsistency. in general, I would suggest failing something for any SCs it fails. while this particular example may be an edge case, it's important to clearly be able to say if an SC applies or not in that particular case.
if it were something like
<button type="submit"><img src="..."></button>i'd fail the
<img>under 1.1.1 for lacking a text alternative, which then leads the<button>to fail under 4.1.2 as it lacks any other means that would provide an accessible name.similarly, if it were a link
<a href="..."><img src="..."></a>i'd fail the
<img>under 1.1.1, leading to the link failing 4.1.2 for lack of accessible name, and also fail under 2.4.4 and 2.4.9 because the link has no actual link text.in the case here
<button type="submit" />though, i'd say there is nothing - no text, no non-text - inside that button. all users will experience this as a generic empty button (sighted users will see it, and non-sighted users will have their AT announce it as a generic "button", so from that point of view the button itself is non-visually conveyed appropriately). so i wouldn't fail this under 1.1.1. I would fail it under 4.1.2 for lack of accessible name.
now the open question, as said, is whether or not those three cases would also fail 3.3.2. as currently written, 3.3.2 seems to only apply to inputs where a user needs to enter information. i'll assume that it also intends to apply to things where a user makes a selection, like
<select>, or groups of radio buttons, or checkboxes - though strictly the normative SC language could potentially be read very pedantically to question whether it's an input there or not.now, does activating a button (to trigger an in-page action, like opening a modal dialog or menu, or to submit a form) count as an "input"? and if yes, does activating a link also count as an "input"? this becomes a can of worms, as suddenly 3.3.2 may actually apply to links and cover the same/similar ground to 2.4.4/2.4.9...