Cursor as sole focus indicator of inputs sufficient to meet 1.4.11? #680
Comments
|
i would say yes. 1.4.11 does not require field boundaries or anything else to be shown for things. and the caret provides a visible indication of where the focus is. |
|
I would say no, unless the field is always focused (and that's a bizarre edge case that I wouldn't mention in the understanding doc). If the only way that you know that the field is there is from the caret then you wouldn't know that it is there unless focused. Related to the caret, that can help you meet 2.4.7 Focus Visible - the Understanding document says "Note that a keyboard focus indicator can take different forms. One common way is a caret within the text field to indicate that the text field has the keyboard focus.". But then 1.4.11 needs to be applied to the caret if that is relied on to show the focus. |
|
Well, the thing is that the search field only gets displayed when you activate the loupe icon first, so in that sense, yes, when visible, it has the focus. |
|
ok, so maybe this is an example where it would count, but I'd sure feel more comfortable if there was a line under or around the input. |
|
@detlevhfischer can you provide the link to the example? wondering if the input disappears on blur, and is shown (none / block) on click... / |
|
@jake-abma has come up in a current test that is still ongoing, so I'd rather not -- in any case, it seems to have been fixed now (or appeared in circumstances I cannot reproduce) - there is an bottom line and even a floating label now. |
|
If I'm understanding what you're saying @detlevhfischer I've encountered this design before, where the search input is not displayed persistently. I think it's really undesirable. As for the absence of any cue for the input except the cursor -- no border, no preceding label -- I'd love to see some usability testing. |
|
I think it's a gap in the current WCAG requirements for visual affordance. It's definitely a user issue for me. |
|
What's the gap, Jon? Is Detlev's example more common than I think? |
|
I see this occasionally. I don't know what SC it fails under -- SC 1.4.11 only requires contrast for aspects that appear visually already -- it doesn't mandate affordance if none is provided. |
|
@mraccess77 yeah, kind of. 1.4.11 requires contrast for the visual elements required to identify the control, so there needs to be something there that has contrast, right? In this case the question is whether the caret is enough. |
|
We agreed before that 1.4.11 doesn't require adding a border when one wasn't already present. Only if a border was there it had to have sufficient contrast. So the caret is the only indicator and the caret itself would need to have sufficient contrast. I agree it's a gap but that's my recall of what we agreed to. The caret is enough to pass 1.4.11 but not enough for real users. |
|
Yes, I think that we are agreeing. Maybe? In the Understanding document it says "any visual information provided that is necessary for a user to identify that a control is present" - presumably there is never a complete lack of information provided for a control, so that is why I'm saying that there must be something that identifies the control. If I had a page with a form like this (http://awkawk.github.io/secretinput.html) which SC would you say that the three fields triggers a failure on? |
|
Those examples don't violate any current SC. Wr need an SC to deal with those situations. |
|
I'd agree for the second two, but not the first. The first shows nothing to let you know that it is there. It certainly fails the focus visible from 2.0 and I think it should fail 1.4.11 because the information needed to identify the presence of the control is invisible (less than 3:1). I meant to make the second one fail also, with a light colored caret, which I have now done, so I could say that the second fails 1.4.11. The third is ok. Are you seeing it differently? |
|
splitting hairs perhaps (would i EVER do such a thing?), but the lack of border or anything else around those inputs means that there is nothing there that fails the contrast ratio? i.e. there is no "visual information required to identify user interface components" at all, so can't check for contrast? the SC itself doesn't mandate (in my reading anyway) that user interface components must have visual information to identify them...but that if they do, THEN this visual information must have a particular contrast. further, not having any border at all disadvantages every sighted user, rather than disadvantaging users with particular disabilities? |
|
in fact, my reading seems to be backed up by the understanding document https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html
|
|
I agree with Patrick's reading -- however, I don't agree that it impacts everyone equally. It's a much higher load on people with cognitive and learning disabilities as well as people with low vision who may miss things like visual spacing that adds a clue. Mouse pointer hover clues might be missed by someone who can't use a mouse and navigating by voice commands to guess what fields might be there could also be an issue for users of speech recognition software. |
|
To be clear, I didn't say that the SC required a visual boundary. However, there needs to be SOMETHING that makes the presence of the field known and that something needs to meet the contrast ratio. That is why I agreed that Detlev's example would pass with just the caret. But if the caret was 2.5:1 then it would fail. |
|
A lack of focus would be a 2.4.7 failure -- a focus indicator such as the sole use of a caret with limited contrast would be a 1.4.11 failure. But if the caret only is there with 3:1 contrast on focus then it would pass both. When I first looked at your example I was using Safari on my iPhone and they all were the same. When I looked with Chrome my my laptop your #1 example would fail 2.4.7. #2 would fail 1.4.11 if it is < 3:1 and #3 appears to be > 3:1 so it would pass. But I still think there is a gap for users regarding affordance that the fields are input fields until focused. |
|
This seems to boil down to the need for a new SC that doesn't just say a control's "states" need be discernable #686 ... but the actual control itself needs to be discernable. (rather than trying to retroactively extend the meaning of these SCs)
Again, cautioning that we currently have no SC that mandates the "there needs to be SOMETHING" for when the field doesn't currently have focus. |
|
can we conclude here we like to propose a "Interactive Controls Visible" SC for 2.2, @mraccess77 from within the Low Vision Task Force? |
|
So, the interpretation is that "visual information required to identify user interface components" means that if visual information is provided (e.g. a light gray outline or underline for a text input) then that outline needs to be 3:1 if it is the only way to identify that the text input is present, but if the light gray outline is changed to no color (or to a color that matches the page and component background color) then it doesn't apply? I suppose that there is a reasonable argument to be made that if a control is made invisible against the background that it is a problem for all users, but it seems problematic that a contrast ratio of 0 passes but a contrast ratio of 0.0001 fails. |
|
@awk wrote:
That may be true to a certain extend, but if a disproportionate burden is much higher for people who are zoomed in and can not make up the possible 'hidden' UIC because they lack context other people do have, or context which is much more easily not seen by people with cognitive difficulties, you might say the challenge is not the same. Recently I had a kind of the same challenge, figured it out pretty fast while others may have never seen it. See image... the inputs are beneath persona, title, date. Only after clicking on it you know they are inputs
|
that's exactly the situation we've had for years with "focus visible" and its lack of definition for "visible" |
|
@patrickhlauke so, what does that make you conclude about 1.4.11? |
|
Hi Jake, not sure if LVTF will be taking up new SC -- but this seems like it also may relate to something that COGA or mobile TF are looking into. |
that 1.4.11 was used to patch that particular gap for focus indication. and that it can be used to patch the gap for another (not yet written) SC that mandates something similar like "controls visible". but that otherwise, if you wanted to make 1.4.11 also explicitly mandate borders or similar, then that would be normative change to 1.4.11 which i'll assume is too late to do now. |
|
dredging this up again, as somebody asked a related question at work pointing to an apparent inconsistency in the understanding 1.4.11 document https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast Under the "Active User Interface Component Examples" section
But the image there shows the text input, and the focus outline on that input yes...but there's a caret also shown. This seems to then suggest that yes, regardless of caret, the outline must have sufficient 3:1 contrast. But if that outline is secondary, and the state of the input (it being focused) is already indicated by the presence of the cursor/caret...then it's irrelevant whether or not that outline is contrasty enough, no? |
I don't agree with this. You are suggesting that 1.4.11 is only applicable to the focus contrast, and that isn't accurate. The SC says that "visual information required to identify user interface components" needs to have a contrast ration of 3:1.
I agree that the carat is generally not sufficient to indicate the component. I agreed that this particular example might satisfy the SC if the only time that it appeared on a page it is focused and shows the caret. If this is one of 5 inputs on a page and the only way to know where the input is on the page is to see the caret then it would fail 1.4.11. However, it isn't necessarily about having an outline on the input so much as having some way to know that the control is there, which may be by having a different background on the page and the inputs or an underline (these do make an effective outline for the input, but we didn't state it that way because it can be handled external to the input). So, if I have an input control that has a 3:1 contrast solid line under it (or on on the left edge, or any other way to know that it is there) and it has the regular caret when focused, and it also has an outline that is 2.5:1 relative to the background, that will not fail 1.4.11 or 2.4.7. |
but the SC itself doesn't mandate that user interface components MUST have visual information required to identify them...just that if they do have the visual information, THEN it needs to have a contrast of at least 3:1. no?
but again, why? does the caret not count as visual information that identifies what currently has focus? it's something visual, and - assuming it's contrasting enough - visible. currently, that seems all that's normatively required until there's an SC that mandates something "stronger"? |
|
I see 2 different situations
|
|
(noting that i am here, in part, taking an extreme stance thin-slicing the normative language. i'm not arguing that borderless/outlineless/featureless inputs are in any way good...but trying to determine if they unambiguously fail the SC or not, and it seems that because the SC itself doesn't mandate that these controls HAVE to have visual information that indentifies them, nor normatively defines what this "required" visual information is, there's a potential loophole/gap) |
|
@mraccess77 are your two situations on the same control on the same page? It sounds like what we need to get the WG to clarify is whether the contrast for visual information needed to identify a control extends to whether the control is visible at all. @patrickhlauke no worries, we are all arguing for better accessibility and it is important to hit the language hard to identify cracks. |
|
@awkawk same control - same page -- just focused in one and not in the other. |
|
A small text replace to simplify the SC normative text only for UICs, without states, ends up with:
Is it correct that if we agree in the WG that "visual information is required for identification of (all) UICs, plus enough contrast", than if fits under this SC and we should update the Understanding doc. We don't need another SC for UIC to make them apparent with enough contrast and catch default and states in this one. If we don't agree visual information is required for UICs, this is not the SC to discuss, don't have another one to place it under and may come up with another one in future... |
|
@jake-abma i'd say i probably agree with the first, that the intent was to have - to use a quickhand synecdoche here - borders/outlines or whatever for inputs contrasty enough to make them actually visible. the loophole i see is that this still doesn't normatively define what "visual information required to identify user interface components" IS (could an author add a single high-enough contrast dot in the top-left corner of their otherwise low-contrast border and claim that that is the only "required" bit?), nor whether or not UICs that don't have any visual information at all (in the extreme case) fail this automatically. granted, these are edge cases...but i've seen my fair share of developers who will try to "just get it over the line" with creative interpretations of SCs. (as for @detlevhfischer's original input there in the thread starter though, i think we agree that since the input doesn't actually "exist" on the page unless it's focused, and the caret/cursor is contrasty enough, that does nominally pass 2.4.7 focus visible AND 1.4.11, right? it's another special/edge case?) |
can't we just define / explain the intent in the Understanding doc what is needed for all UICs, default as well as states, knowing that if you want to play it hard and only add 1px you're just ignoring the fundamentals. We can add / explain the visual needs and if people try to get a free card we can't stop that, in that case you're just being the bad, bad developer... :-) |
|
you can define a lot in understanding, but as that's only informative and non-normative, you open it up to "well that's just one opinion of many, and it's not exhaustive" |
|
Related: I have created a pull request #701 for the 1.4.11 Understanding text to include placeholder text as visible indicator for boundary-less controls. I think this is in line with the button example which has only text but no (or low-contrast) boundaries and conforms based on sufficient text contrast. |
|
sorry for even raising it as it's such a trivial thing, but shouldn't the success criterion read "The visual presentation of the following has a ... " rather than "The visual presentation of the following have a ... "? that is, the subject 'visual presentation' is singular, but the verb 'to have' is plural? |
|
To note, we are exploring the addition of a 'size' component to focus (more) visible, which would mean that cursors (flashing vertical line) are not enough to indicate focus. Unless it was super thick anyway. |
|
Hi @alastc didn't have edit rights but for https://docs.google.com/document/d/1g9_WBgfhViWAaRFIWWt10CP5rBsEVIWm3vT1vWqrHvI/edit?usp=sharing it may be a good idea not to talk about "change of color" but as you already explain it for contrast changes, make it "change of color contrast" (saves a lot of misunderstanding) Cheers! |
|
Hi @jake-abma, thanks, I’ve updated the doc with that. |
|
Hi everyone, I've re-read this thread to see if there are any updates to non-text contrast (NTC) understanding, and I can't see anything immediate. There is an assumption baked into NTC that there are visible indicators for everyone, and a sub-set of those ('Visual information required to identify') require contrast. Unless someone can think of something to add, I suggest we close this. With the new focus-visible (enh) SC in 2.2, I think some of the niche cases above will be better covered and (when that's approved) we can update NTC so it references focus-visible instead of trying to cover that. |
|
This issue looks like it can be closed. If it needs to be re-opened, please do that and convert it to a Discussion. |
We have a case where a search input field is only indicated by a blinking cursor (the vertical caret line has sufficient contrast) - no field boundaries. Would that be considered a minimal pass of 1.4.11?
The text was updated successfully, but these errors were encountered: