0

When reviewing possible failures to WCAG success criterion 4.1.2 I encountered a mysterious Failure of Success Criterion 4.1.2 due to the focus state of a user interface component not being programmatically determinable or no notification of change of focus state available"(https://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20161007/F79).

While the article identifies the failure, it does not clarify how to achieve compliance for custom components.

Hence, the question - what is the standard way of exposing focus state via the Accessibility API for custom controls in React? Does HTMLElement.focus() handle it gracefully, or are any other actions needed?

TylerH
  • 20,799
  • 66
  • 75
  • 101
Anastasia Pevtsova
  • 55
  • 9
  • Normally, any element that you wish the user to interact with by mouse, should have `tabfocus`, if it's not possible to reach it by tab otherwise (forms and links usually). If you have an element in a page that is interactive, it should be possible to navigate to it using only a keyboard, that's pretty much it. – David T Feb 06 '20 at 10:05
  • 1
    Can you post some code of the custom element for which this issue occurred. Ideally providing role, state, and value information to the custom component should resolve the issue. – tarzen chugh May 02 '20 at 11:55

1 Answers1

0

You can only really call focus() on an element which has a tabindex attribute. (Exceptions to this rule are 'native' UI elements such as button, a and input, which are focusable by default).

If you want to focus() something without including it in the tab sequence, use tabindex="-1".

For components, you'll have to choose carefully where to put the tabindex. Typically you put this attribute on the element which carries the semantics. (i.e. if you want to focus on a <h1>, use <h1 tabindex="-1"> rather than on any wrapper elements or descendants). This might be more tricky with components, especially if the component is a composite widget, but that's another story.

brennanyoung
  • 6,243
  • 3
  • 26
  • 44