search

dequelabs / axe-android

WCAG Accessibility compliance library for Android Applications.
Mozilla Public License 2.0
65 stars 19 forks source link

Focus Order #17

Open chriscm2006 opened 5 years ago

chriscm2006 commented 5 years ago

Accessibility Focus order should match Focus Order.

Effected Technology: TalkBack, Keyboard Nav, Switch Control Type: Moderate - WCAG 2.1 - Best Practice Success Criteria: 2.4.3

User Story

screen shot 2019-03-04 at 2 08 09 pm

Inaccessible

As a TalkBack User

  1. Open an Activity and Swipe Right repeatedly a. Accessibility Focus moves to View 1. b. Accessibility Focus moves to View 2. c. Accessibility Focus moves to View 3.
  2. Reset Activity and Hit Tab Repeatedly a. Focus moves to View 1. b. Focus moves to View 3. c. Focus moves to View 2.

Accessible

The above actions would be made Accessible if the navigation order matches. The preferred order in this case would be 1 -> 3 -> 2, but would not explicitly be checked by the rule.

goodwitch commented 5 years ago

@chriscm2006 I don't think we talked about this one while I was in Ann Arbor. The normative text of 2.4.3 reads "If a Web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability."

So, what you describe above is a needs review item...because it would have to be manually checked by an expert for the "order affects meaning" part. In other words, this is not eligible to be an automated failure of WCAG normative.

For reference, see Deque Way documented Best Practice: "Focus order identical - Focus order and DOM order should match. (structure-dom-visual-mismatch, "best-practice", impact 2, March 26, 2013)"