Clarify what is meant by "When user interface components receive keyboard focus," in SC 2.4.11 #2219
Comments
|
I'm sure we discussed some of this previously in some other issue, but can't find it now. I think it was in the context of whether something like |
|
I find the idea that a transitory indication of focus is adequate to conform both incorrect and objectionable. Focus indicators represent a state of being focused, change in the display indication when the control is in a focused state implies a change in state, which has not occurred. |
|
I agree Steve - and so I think the wording may need to be updated or at least the understanding document updated to clarify (I think we were discussing that but I couldn't find an open issue on it). Some users with visual impairments cannot track the visual cursor or even see the whole screen at once (those with visual field loss or scotomas and may not be using magnification software that tracks the view) and may need to scan the page searching for the indicator. |
|
I've had questions about this as well. @mbgower had some examples I think. I've grappled with this SC a lot - just as we are asking what the examples are where the focus needs to disappear, I'm also wondering how much of a problem it is that the focus is not persistent. I can see how it is a problem if the focus isn't shown - even with a mouse people have this location problem and Windows has included a feature to help people find the mouse (https://support.microsoft.com/en-us/windows/find-your-mouse-pointer-fast-dbc1d222-778c-da15-5218-cb8336074554). That said, I know that when I use the keyboard to navigate that I regularly lose track of the focus even when it is quite prominent - I'm thinking about other things / the UI has a lot going on and even though the focus is prominent it can still get lost / etc - and the way that I reorient is to tab a couple of times and shift-tab if needed. Has focus disappearance been a major problem that 2.4.7 Focus Visible hasn't been addressing? |
In my experience, it is not uncommon for users with low vision to have significant difficultly with pages that conform to 2.4.7. So I agree we need more, and I understand this to be the motivation behind 2.4.11. But I can't say that "focus disappearance" is a problem with 2.4.7, only that 2.4.7 has not been enough to many users. On the other hand, if I think about enhanced cursors which are available via AT — those do not disappear! Moreover, given how long it typically takes someone to find those AT-enhanced cursors, focus disappearance would be obviously problematic. |
My recollection is that there are some scenarios where the author may struggle to prevent a focus indicator (and/or the focused item) to be hidden. Either outside the viewport (by scrolling) or if the user triggers content that overlaps/obscures the focus. (Some drop-down menus show this, although I don't have an example to hand.) I don't think we had considered a fading indicator at the time. It partly comes down to whether you consider the focus-indicator part of the component, regardless of what's going on around it, or whether you consider the page as a whole. We can't have the 'partially obscured' bullet unless we consider the whole, in which case we need to allow for scenarios where it may be partially hidden. E.g. a zoomed in page that has a chat button attached to the bottom-right of the viewport. That might overlap the keyboard focus sometimes, depending on the scrolling and positioning, but it isn't a big issue in practice. (Unless it completely hides the focus.)
I know that has been discussed, I'm not sure if it was a factor for this bit of the SC text. The latest wording includes "keyboard operable" though, which should allow for focus-visible.
We use focus-visible to fail things that take focus and aren't visible, including the element itself. Fading indicators are very rare though, I can't recall coming across many in our audits. I guess it could become more popular after this SC is added, creating an incentive to fade them perhaps? Would others agree that a focus indicator that completely fades would fail 2.4.7, regardless of the new SC? |
|
I would consider a fading indicator a failure of SC 2.4.7. |
|
I must confess, it had not occurred to me to consider a fading indicator under SC 2.4.7. Sorry to say, I do not think a fail is unambiguous. Ping to my colleague @kengdoj to say if this detail is covered under Trusted Tester. I will also note that, prompted by this other 2.4.11 thread I am now using the built-in Chrome feature for an enhanced focus indicator. The feature makes interesting choices when focus moves to anchors which are not UI components, for example the target of a skip nav. It is good that we are limiting 2.4.11 to UIC. |
|
I have to agree with Bruce. I don't think that 2.4.7 makes it clear that the focus must be persistently visible. However, in the Understanding document there is this sentence: "The focus indicator must not be time limited, when the keyboard focus is shown it must remain." so apparently the Working Group intended it to be persistent, even if there may be a mode that doesn't show the focus. |
|
@bruce-usab the understanding doc is unambiguous:
source: https://www.w3.org/WAI/WCAG21/Understanding/focus-visible.html |
|
If we start down the path of saying that if it does not explicitly state that it must be persistent then many a success criterion could also be open to that interpretation.
but only for the first 20 seconds of display… |
|
Indeed, we've had that conversation in the context of labels before, and we came down on things needing to be persistent unless stated otherwise. |
|
I appreciate the notes that persistence is included in understanding. Any ideas where we might include that expectation somewhere in the main document? I would not like to see it added on an SC-by-SC basis. But here is an unhappy thought: If persistence is added as a condition to 2.4.11, there is an implication that persistence is not required by 2.4.7. |
At least the normative wording for 2.4.7 does not include any of the problematic "when it receives focus" language, which caused this whole discussion in the first place here for 2.4.11. 2.4.7 is problematic anyway because it didn't normatively define what "visible" actually means, so I think the ship has already sailed in terms of unintended readings of 2.4.7. (as in there's already so many loopholes in 2.4.7 - see for instance my "ad absurdum" idea of a single pixel focus indicator in the faintest possible colour, which would normatively count as "visible" and pass the SC - that I think it's not worth worrying how much further 2.4.7 could be perverted/circumvented. heck, imagine adding "persistent" to 2.4.7 ... it would still leave the option of having a very "visible" good focus indicator when it first receives focus, and then fade into a single-pixel one after a second. that would satisfy the current 2.4.7 even if it was modded to include persistence) |
|
I've been thinking about whether the focus appearance SC should basically copy 2.4.7 and add in the new bit with a definition for "highly visible keyboard focus indicator". Like this: And then the details about contrasting area, etc go into the definition. |
|
2.4.7 doesn't get us much in the way of measurable normative language, but it at least provides a way to fail when something lacks a visible focus indicator. Focus Appearance has 2 goals:
I used the "when" phrase to accomplish the second goal. Its purpose is to keep the item with focus from being obscured. Floating footers, non-modal dialogs, and a few other increasingly used authoring techniques have been making life harder for sighted keyboard users. This seemed like a solvable and worthy problem. I had not thought about the "when" language being interpreted to allow or encourage fading indicators. It seems to me it should be easy to add some wording in the understanding document about persistence and intention. Because of the way the 2nd objective has been made something of a younger sibling to the first, I could also see us just putting the "when" language there, which might get us roughly to something like:
I'm a little concerned with the perfect being the enemy of the good with some of our work. This SC in its current form will improve the experience of users. If it can be further improved upon, excellent. But the more we try to shore up against all possible forms of implementation idiocy, the more unfathomable the wording threatens to become. The current Focus Visible, with all its warts, has still had value. I think the same can be said of the new one in its current form. |
It could be that 3.0 could evaluate adding persistence as a high level conformance requirement. But I anticipate some unintended consequences we'd have to try to anticipate. As per my last comment, there are countless ways to make content unusable. We have to make some assumptions that a bad design (i.e., a. page with no content; a page with text so small no one can see it, etc) is going to be a bad experience for enough typical users that it's not primarily or markedly more of a problem for users with disabilities. Issues related to keyboard interaction tend to be defensible as markedly more of a problem. |
|
To respond to @bruce-usab asking if this detail is covered under Trusted Tester: Trusted Tester's test condition for this is "A visible indication of focus is provided when focus is on the interface component." In order to pass, the focus must be visible while the component has focus. If a focus indicator were to fade to invisible while the component has focus, Trusted Tester would fail it for 2.4.7. |
|
The Trusted Tester wording lacks the nuance of "has a mode of operation where the keyboard focus indicator is visible". How would TT work against things like |
|
@patrickhlauke - sorry, I did not include the instructions for Trusted Tester in my earlier comment. Here is a fuller clip:
The test would not cover when focus is received as a result of mouse/touch interaction. |
|
@kengdoj ah, phew...that's good to know |
I guess it comes down to how you interpret "mode of operation". The point of discussion is 'how does the designer know how any user is going to operate the revealed menu? The assumption is that if someone last operated with a mouse, they are going to do so in their next interaction. But User X doesn't have good precise motor control, so when User X opens a dropdown (whose menu items tend to have smaller vertical hit areas abutted to one another), User X always operate by keyboard to ensure the intended item is chosen. So User X is now trying to use a keyboard; however, cannot tell if the focus is on the dropdown 'button' or on one of the menu items. Is the focus on the dropdown of the Watch split button just clicked? On the Not watching menu item, which is first in the list and has a check mark? How about in this situation, where the current selection is Watching Is the focus on the dropdown? On the Not watching menu item, which is checked, or on the Not watching item, which is first in the list? I hope most would agree that if the focus was shown, this is a better user experience for many. Some designers do not (including, one assume, the Github designer) and don't want it to look like this: I imagine we could get in a debate about whether this fails Focus Visible, with many (the majority?) noting that the mode of operation to get the focus is to use a keyboard. Since a mouse opened the menu, no focus indicator needed. That seems like it is Trusted Testers stance. Without getting into that debate, I'd like those users to think of this situation. I activate the dropdown by mouse, but I dismiss the dropdown menu by pressing Esc. So I've just used my keyboard. Should the focus now show on the dropdown target? Not to pick on GitHub, but they do not; after escaping the menu, absolutely nothing has a focus indicator. I think that is likely a common implementation for those who follow this split design modality approach. One of the questions in my mind is whether the "When user interface components receive keyboard focus" makes it clearer whether that is a failure. |
|
as otherwise, the only answer to "'how does the designer know how any user is going to operate the revealed menu?" is "they can't know, so they must always assume keyboard", which is simply not going to fly as a requirement (and it would make for a fairly horrid user experience for mouse/touch users in many situations) - particularly since designers that have been trying to square the circle of providing focus indications in a way that doesn't necessarily impact mouse/touch use have been waiting for years to get something like
yes, ideally it should. if it currently isn't (i can see at least in Chrome that despite the programmatic focus going back to the button, it's not showing in that scenario) that seems a fault/shortcoming of Chrome's current logic for when it's applying its focus outline heuristic (it doesn't seem to take |
|
2.4.7 is now unfortunately formulated in such a way that it does not require a focus indicator for mouse operation, but for keyboard operation. But changing the operating mode (from mouse to keyboard) should not be a problem (not even in your example), because although I do not see any focus in mouse operation, the moment I start navigating with the keyboard (i.e. after the first arrow key operation) I see the focus. Thus 2.4.7 is fulfilled. Of course, a focus criterion that also applies to mouse operation would be ideal, especially since 2.4.7 also mentions mouse users in Benefit. |
I can see some folks not agreeing with you that it has to be navigation. I think a very good case can be made that when I dismiss the dropdown with Esc, I am in a keyboard 'mode of operation' and the focus should be present.
I agree it should be beneficial. There are people who disagree with that, but I haven't seen implementations where clarity is lost or a user becomes confused because the keyboard focus is shown. If anyone has someone, I'd sure like to review and get a better understanding. The primary objections of designers tend to be it is inelegant (aka 'ugly', 'too strong', etc). |
the secondary objection is that it makes "immediate action" type buttons all of a sudden look different - say you have a left and right arrow button on a carousel. you click with the mouse / tap on a touchscreen on one of them, now they look different. does a user understand that it just looks different because one now has focus, or is it because they now act/are different ... is one disabled one perhaps, is that why it has that difference in styling? also, note that this has been browser behaviour for the default focus outline for ages ... browsers applying a "which input caused this to get focus" logic in deciding whether or not to show the default outline. so this should be tied to an option in the browsers.
then that argument needs to be made to browsers, because they're currently not doing that for their default focus outline nor the |
also, let's be clear... not just "designers", but actual clients/CEOs/etc that pay for sites to be made... |
|
The keyboard user has this same issue "the secondary objection is that it makes "immediate action" type buttons all of a sudden look different - say you have a left and right arrow button on a carousel. you click with the mouse / tap on a touchscreen on one of them, now they look different. does a user understand that it just looks different because one now has focus, or is it because they now act/are different ... is one disabled one perhaps, is that why it has that difference in styling?" So while that is an issue for touch/mouse users - we need to solve that in the future for keyboard only users as well. |
Correct; Trusted Tester (TT) wouldn't check for a focus indicator here.
Hmmm, not by using the Esc key. The TT test instructions are "Use the keyboard to navigate". The Esc key doesn't shift focus so it would not be considered as keyboard navigation. The keyboard navigation keys are Tab, Shift+Tab, Ctrl+Tab, Ctrl+Shift+Tab, Up Arrow, Down Arrow, Left Arrow, and Right Arrow. If, after clicking on the button with a mouse the next key press was a navigation key, a visible focus would be expected. For User X: select the GitHub Watch button by mouse, then press the up/down arrow key and the option with focus has a visible focus. |
arguably, not the same way, as the keyboard user is used to seeing an actual focus indication as they navigate through the page, so they're likely less surprised by the fact that the button that they've placed focus on now appears differently, and will likely infer from it that it's some form of focus indication.
I hope the "we" here is more of a general "we as the web development/design community". because if it's "we" as in AGWG ... i can foresee endless debates on what constitutes the "right" design/look-and-feel, which frankly to me goes beyond what the AGWG could and should mandate (and, as a result, "legislate" really because WCAG makes its way into actual legal requirements as a benchmark) I shudder at the thought of WCAG being the source of an "approved" international visual style for web development. |
that seems like a gap if so. Especially in regards to test 4.H |
|
"arguably, not the same way, as the keyboard user is used to seeing an actual focus indication as they navigate through the page, so they're likely less surprised by the fact that the button that they've placed focus on now appears differently, and will likely infer from it that it's some form of focus indication." I'm not sure I agree - on many pages I find multiple types of indicators on the same page - sometimes 5 or more. Also with a magnified view I may only find a few controls in view at a time - one button is white on green and the other is green on white - it's honestly not clear to a keyboard user which is the focused and which is the unfocused state. Focus states are very often just inverted colors or similar and often don't look like indicators. So it really depends on the quality and consistency of the indicator. |
|
This conversation has spun a bit out of orbit of the original question (and I'm one of the contributors to that). I just wanted to make sure that a comment of mine from a week ago got some eye balls. I'm suggesting moving "when" out of the preamble into the second section. This is it in rough form:
|
|
The changes from #2281 separate the 'when' from the appearance criteria, so closing this one. |
I had understood this to meant that when the user scrolled the component out of view that it didn't need to have a focus indicator - but that while it is visible and focus hasn't been moved the focus needed to persist. Others bring up the point that it only means at the exact moment it receives focus does it need to have an indicator and the indicator can disappear. Can we please define what is required. In addition, if is in fact that it only has to briefly appear on focus and can disappear a second later - are there any other success criteria in WCAG that do require focus persist while the control is visible in the viewport and the user has not moved focus?
This difference seems to be related to discussion in #2201
The text was updated successfully, but these errors were encountered: