0

I'm working on a site that requires WCAG 2.0 AA adherence, but although we try to make tab navigation usable on our sites, it does detract heavily from the design due to the strange borders and outlines being rendered when you click a focusable element.

My thinking is, hide all focus states until the tab key is actually pressed.

So, my question is, does this pose any potential problems with accessibility technologies for the web?

thephpdev
  • 1,097
  • 10
  • 25

1 Answers1

5

Remember that sometimes focus is placed on elements without using a keyboard, such as via script or third-party tools (like screen readers prior to page interaction). Also note that even screen reader users do not necessarily use the Tab key (for example, I can navigate the headings on a page by pressing H in most screen readers, and on mobile I can navigate a page elements without using a keyboard at all. Also note that some users with cognitive impairments benefit from focus styles even when using a mouse.

As such, if I were reviewing a site that disabled focus styles only until someone pressed the Tab key, I would still fail it for 2.4.7 Focus Visible. It might be helpful to read the Understanding SC 2.4.7 document for a little more context.

To answer your question, yes, removing it does post potential accessibility problems.

All that being said, I would instead challenge the designer to do what designers tend to do best — work within constraints. Come up with focus styles that are not distracting, with styles that are perceivable, operable, understandable, and robust (so, for example, it meets contrast minimums). It has been done before, so there is no reason it cannot be done again.

aardrian
  • 8,581
  • 30
  • 40
  • thank you for your answer! That makes sense, I had a feeling this would be the case anyway. We have already designed such focus states, I've just always thought that a button looks weird when you add an outline or a coloured glow or some other focus indicator when you're just clicking it with a mouse. Be good if there were some standard, cross-browser API for accessibility, so we'd know when its actually being used. Us developers can only dream. – thephpdev Jan 10 '17 at 15:01
  • There is a cross-browser API, it is what screen readers rely on. We as developers use HTML, CSS, JS, and ARIA to affect what is passed via that API. The issue is that what the assistive tech does with it from there is up to them and requires testing on our part. Not easy, but at least there are plenty of people who do it and write up their findings. – aardrian Jan 10 '17 at 16:55
  • I'm quite aware of ARIA, I'm talking about some kind of way of checking of the user is currently using assistive technologies, then the experience could be tailored for such users. But I doubt we'll ever see such a thing any time soon. – thephpdev Jan 10 '17 at 17:48
  • 1
    No, I suspect not. In general users of assistive tech do not want to be detected and some go to lengths to prevent it. Lots of history suggests it will result in worse (abandoned forks, missing features, etc) experiences. So, yeah, probably best to pretend that will never be a thing. – aardrian Jan 10 '17 at 17:59
  • 1
    I wear glasses occasionally so that I can read the text on a page when my eyes are tired. Glasses are my assistive technology device. Without them, I would not have access to the page so it's an accessibility issue. Do you want to detect when I'm wearing glasses? – slugolicious Jan 10 '17 at 22:52
  • 1
    One clarification on @aardrian's last sentence in his answer, "Come up with focus styles that are not distracting, with styles that are perceivable, operable, understandable, and robust (so, for example, it meets contrast minimums)." WCAG 1.4.3 only deals with text and not focus indicator so a focus indicator doesn't have to meet contrast minimums. It'd be nice if it did but it's not a requirement. Although it's a little vague because the spec says the focus indicator should be "visible". What does "visible" mean? It might mean it needs sufficient color contrast. It's kind of debatable. – slugolicious Jan 10 '17 at 22:58
  • 1
    Yeah, since [2.4.7](https://www.w3.org/WAI/WCAG20/quickref/#qr-navigation-mechanisms-focus-visible) states it must be visible and [G195](https://www.w3.org/TR/WCAG20-TECHS/G195.html) suggests highly visible, and there are existing bugs against the browsers for default focus indicators that meet 1.4.3, I err on the side the user over the spec and go for meeting the contrast. So yeah, it is debatable, and I am clearly happy to do that. – aardrian Jan 11 '17 at 00:57