0

Background

I have a site which has a master/detail sort of design. The master view is a column chart where clicking on one of the columns (each column represents one month) changes the detail view (which is a nested table listing some details of that period). I've started an accessibility audit and as you might imagine, it is not very accessible. I solved the chart by adding aria-hidden="true" and adding an invisible table with the same content with buttons in the month rows. Now activating the buttons will do the same thing as clicking the chart columns - change the detail view.

Moving focus

When the button in a table in the master view is clicked, my screen reader (VoiceOver Safari in this case) reads "Button clicked", but then using the cursor keys keeps reading the table. I assume a user once they decide which button to click would like to read the detail view and so I would like to move them there.

What I have tried

I changed the buttons to <a href="#detail-view" ng-click="loadDetail"> and gave the detail view container div the id="detail-view". This doesn't seem to do anything.

Jakub Hampl
  • 39,863
  • 10
  • 77
  • 106
  • Sending focus to the detail view using the href as you describe should allow the screenreader software to move forward from the new location. And a link is a good way to do this as people expect it to take them to a new location. When you say it doesn't work, can you be more specific about what happens? – stringy Aug 11 '15 at 08:28
  • @stringy 'my screen reader (VoiceOver Safari in this case) reads "Button clicked", but then using the cursor keys keeps reading the table' is what happens. That is the SR just confirms that the link or button have been pressed, but then continues reading in the current position in the table. – Jakub Hampl Aug 13 '15 at 07:48

1 Answers1

1

Simple answer: don't. Shifting focus around on a non-sighted user is actually an accessibility violation. See WCAG criteria 3.2.2.

In short, you shouldn't initiate a change of context automatically after the press of a button or other control interaction. What you should do is inform the user of the new content, either by an announcement, or by providing a description of the change in the accessibility text of the control itself. An example of providing this context would be announcing your master cells as "tabs". Just the simple association of a button behaving as a tab provides a lot of information!

To make your application more accessible you should ensure the user knows they are in a master-detail type of control, by providing proper role information (I find "tab" most likely here, but other roles may be applicable). Also, provide a heading at the top of the master view, and the detail view, so that they can easily navigate between the two. As long as they know where they are, and can easily navigate to important areas of the page, they are fine. Automatically shifting focus around is actually an accessibility violation, and should be avoided.

MobA11y
  • 18,425
  • 3
  • 49
  • 76
  • I wonder though, if this was a traditional web page, clicking a link would cause a reload and therefore a context shift. So clearly clicking a link you would expect something to happen, no? – Jakub Hampl Aug 13 '15 at 07:51
  • As an aside: WCAG criteria 3.2.2 is about 'changing the setting of any user interface component', i.e. a radio button or checkbox. [This page](http://www.w3.org/TR/UNDERSTANDING-WCAG20/consistent-behavior-unpredictable-change.html) clarifies that 'checking a checkbox, entering text into a text field, or changing the selected option in a list control changes its setting, but activating a link or a button does not'. – Jakub Hampl Aug 13 '15 at 07:54
  • Loading of a link is not the same as clicking on a button. When a new page loads you expect focus to shift to the beginning of the new content. This is very different from the user selecting a button (not a tab or link) and randomly shifting focus. The fact that the control is behaving as a tab is crucial information. A control with the role of a button should never initiate a change in context, without warning. Adding the role of tab or link suggests this change of context, and is a very different scenario. – MobA11y Aug 13 '15 at 17:08
  • Further on down that page you will also see a list of things that constitute a change of context, "Changes in context include changes of: user agent; viewport; focus; content that changes the meaning of the Web page." Extending this behavior to buttons may be "best practicy" and not a pure violation, but I stand by the solution. Informing the user that the control is behaving as a tab and adding headings is more accessible, and easier to implement, than shifting focus around. – MobA11y Aug 13 '15 at 17:15
  • You could also, under this logic, site this as a violation of 4.1.2, which may be more applicable. – MobA11y Aug 13 '15 at 17:22