Focus indicators used to be super obvious in earlier versions of Windows. Sometime around XP (or thereabouts?) they got a lot more subtle. In Win 7 Aero I had to squint to try and figure out which taskbar window is active.
I don't have any special accessibility requirements but I do miss the more distinctive cues. And other ergonomic touches like the little underlines that told you keyboard accelerators (I always turn them on where available).
Finding good, technically-focussed articles discussing accessibility issue best practice (such as for focus indicators) is not as easy as it should be.
I hope the author doesn't mind, I've just updated my lesson[1] on how to make the <canvas> element more accessible with a link to the article.
I’m designing a piece of user interface at the moment, and one thing I’ve been puzzled by is whether keyboard shortcuts should affect the focussed element. I’d love to find out if there are best practices in this area, and particularly if there are accessibility concerns I may not spot.
As an example, consider a page that primarily contains a list of items. I set each item up to be a focus target so tabbing through the targets will select each list element in turn.
If I add keyboard shortcuts to navigate the list (e.g. up/down cursor to select previous/next element), should my JavaScript drive focus to the selected element, or should I use an independent mechanism (adding a class, say) to mark the active element? Driving focus feels like the more ‘native’ approach, but I don’t know if there are downsides to potentially taking focus away from other elements on the page (for example).
I think a roving tabindex would be fine in this case. The arrow keys and tab/shift+tab change the tabindex so you always have elements with tabindex="-1" and tabindex="0".
I like that the focus indicator is separated from the borders of the item, but this raises a problem. CSS doesn't have a way to add outlines separated from the element. This means you have to wrap all focusable elements, and use pseudo-selector :focus-within to create additional border with the wrapper element.
Naturally creating wrapper elements to pass WCAG 2.1 is a pain, that should be solved in CSS itself.
> CSS doesn't have a way to add outlines separated from the element.
Maybe I'm not understanding what you mean but `outline-offset` is a property to set the distance between the element border and the outline (and you can use an negative value to make an inset outline, handy for situations like buttons without enough margin for an outline to appear without being cut off).
You can also achieve a similar visual effect by having a box-shadow with two values, the larger one being your visible outline color and the smaller one matching the background color around the element.
outlines are preserved and used in Forced Color Modes such as Windows High Contrast Mode, where background colors, border colors, and box shadows are usually overridden by user and system styles
Is this actually a thing? If so, how do I test for this (both in CSS and in practice)? I thought only MSIE had this, and MSIE is dead.
Yeah it's still around, high-contast is an OS-level accessibility setting in Windows.
Here's a Microsoft article about designing for users who have enabled high-contrast mode (technically websites don't need to do anything at all, as the default browser behaviour gives a pretty decent result):
Unfortunately, if you want to test high-contrast mode, you'll need a Windows machine (or VM), as Edge doesn't yet have an emulation mode for it (AFAICT), and BrowserStack doesn't let you change OS settings, only browser settings.
Both Legacy Edge and the current Edge also support Windows High Contrast Mode (WHCM) as does Firefox.
Also with Firefox, on any platform, you can go into the settings, Colors, and set "Override the colors specified by the page with your selections above" to Always. It won't change the colors to the ones actual WHCM users use but that doesn't matter, you can't know what colors they've set and they could be anything.
Edit: If you leave the Firefox setting on "Only with High Contrast themes," the colors will also be overridden on a Mac with "Increase contrast" set. Technically, this is inaccurate, it's acting as if `forced-colors: active` is true on the system when the "Increase contrast" setting really maps to `prefers-contrast: more`. But macOS doesn't yet have an option to convey `forced-colors: active` so Firefox's choice is probably for the best for now.
I don't have any special accessibility requirements but I do miss the more distinctive cues. And other ergonomic touches like the little underlines that told you keyboard accelerators (I always turn them on where available).