Hide/Show Summit Holdings: Some Accessibility Lessons Kate Deibel <deibel@uw.edu> University of Washington

Motivation for this Talk In April, several discussions began on the systems list for making the Summit Availability be toggled by a Show/Hide button. Three different solutions were offered: Lane Community College (Linda Ackers) Portland State University (Nathan Mealey et al.) Lewis & Clark College (Nick Budak) Each solution provides a good opportunity to explore some key accessibility insights.

Lesson 1: Semantic Markup Each solution offered a different approach to the HTML for the hide/show element: <a ng-click= … > … </a> <button onclick= … > … </button> <md-button ng-click= … > … </md-button> So the open question is which is the best approach?

HTML Options for Building a Clickable Element We have three options: Anchor/link tag <a> Button tag <button> Any element but you add an onclick attribute to it You should NEVER EVER DO #3!!! NEVER!!!

Semantic Markup Use HTML elements based on their semantics Meets the W3C standards Helps assistive technology perform correctly Making a <div>, <span>, etc. clickable is violating those semantic standards! But what’s the difference between links and buttons?

<a> versus <button> The general rules of thumb are as follows: If the click causes the browser to navigate to a new page, use an <a> If the click causes something to happen on the page like a panel opening, a modal closing, etc., use a <button> Of course there are always exceptions: Navigating within a page (like for a skip link or to a #landmark) should be done with a link <a>

Lesson Conclusion: Use a <button> The Show/Hide Summit feature should use a <button> as it triggers the institution listing to be displayed. What about <md-button>? This is an angular element. It actually ends up producing a <button> element. It does add the markup type="button", which is even better markup It does also add some CSS styling which is nice

Lesson 2: Keyboard Navigation In the Primo NUI, we can generally only add new code AFTER the section we want to change. This causes a navigation accessibility issue. Screen readers and keyboard-only users move: “Down” the page’s DOM by the TAB key “Up” the page’s DOM by the Shift-TAB keys What does this imply for our Summit Button?

The Crux of the Issue Here’s the DOM (Document Object Model) layout: <prm-alma-more-inst> <md-tabs> <!-- summit holdings --> </md-tabs> <prm-alma-more-inst-after> <button>Show/Hide Summit</button> </prm-alma-more-inst-after> </prm-alma-more-inst> This is the crux of the issue: When you click the button, md-tabs shows the Summit holdings, but the user’s focus is “below” the button! How does the user get to the holdings?

Button Misplacement The keyboard/screen reader user could use Shift-TAB to move up the holdings, but it’s awkward. What we really need to do is move the <button> before <md-tabs>? But how? When?

Which approach is the right one? Two Approaches function hide_show() { /* move the button on every click */ } this.$onInit=function() { /* move the button when Angular first loads up the button */ } The option on the left moves the button every time it is clicked. The right option only moves the button the first time it is loaded by Angular through the use of the built-in $onInit() function. Which approach is the right one?

DOM Manipulation and Accessibility Moving elements is best kept to a minimum: DOM manipulations tend to be script-heavy and will slow down a page’s performance Many screen readers will report any changes to the DOM unless the HTML markup says otherwise

Lesson Conclusion: Move Elements Only Once In general, if you want to reposition an element you’ve added to an <*-after> directive, use the $onInit() functions to do it just once. FYI, some other helpful angular functions for working within the lifecycle of elements are described here: https://angular.io/guide/lifecycle-hooks

Lesson 3: Let the Fat Lady Sing Her ARIA ARIA (Accessible Rich Internet Applications) is one of the best ways to achieve screen reader accessibility ARIA lets you add attributes to HTML elements to specifically describe what they do: Provide labels/descriptions only seen by screen readers (or other assistive technologies maybe) Describe if an element is an alert or dialogue What does this button do when clicked? What state is this dynamic widget in? Most page elements DO NOT need ARIA markup though

How do you know if an element needs ARIA? These are the criteria for determining if you need to add some ARIA attributes to your HTML: Is there a form? Is something on the page loaded dynamically? Does content show or hide itself based on a click? Do things move based on a click? Clearly, our Summit Button should have some ARIA markup

What ARIA do we need? The ARIA specification is dense and hard to parse The better approach is to work from examples of good ARIA markup that ARIA experts have put together. Some good sites (with lousy search) are: http://oaa-accessibility.org/ http://3needs.org/en/testing/sr-aria.html https://www.w3.org/TR/WCAG20-TECHS/aria.html http://heydonworks.com/practical_aria_examples/ Also check the ARIA markup on JS Libraries like Bootstrap (versions 3 and higher)

Some Widely Used ARIA Attributes aria-expanded = true/false Used for panels that change in size or show/hide aria-hidden = true/false If true, hides the element from screen readers but may still be visible to sighted users role = [many values] Descriptions of what an element may do: alert, dialog, listbox, menu, etc. aria-label / aria-labelledby = string / elementId Descriptive text for an element given to screen readers only

ARIA for the Summit Button Our Summit Button is about hiding/showing a panel: http://oaa-accessibility.org/example/20/ https://www.w3.org/WAI/GL/wiki/Using_aria- expanded_to_indicate_the_state_of_a_collapsible_e lement

Add aria-controls to button aria-controls="id" says that a button influences the HTML element indicated by the id We have to do two things to our code: Add an id to the md-tabs element containing the Summit links Add the aria-controls to the button’s HTML and set it to the id we just created

Code for adding aria-controls to button HTML Code: <button … aria-controls="summitLinks“> JS Code: // add an ID to the md-tabs element this.$onInit = function() { $scope.tabs = angular.element(document.querySelector( 'prm-alma-more-inst md-tabs')); $scope.tabs.attr('id','summitLinks'); }

Add aria-expanded=true/false to button aria-expanded=“true/false" indicates whether the element controlled by the button has been expanded/shown or collapsed/hidden Our showHide function to do two things: Set the summitLinks panel to show/hide via CSS Update the value of aria-expanded in the button

Code for adding aria-expanded to button HTML Code: <button … aria-expanded=“false“> JS Code: $scope.toggleLibs = function() { $scope.showLibs = !$scope.showLibs; if($scope.tabs.hasClass('hide')) { $scope.tabs.removeClass('hide'); $scope.button.attr("aria-expanded","true"); } else { $scope.tabs.addClass('hide'); $scope.button.attr("aria-expanded","false"); } }

Lesson Conclusion: Use ARIA for Dynamic HTML Figuring out the exact right ARIA can be tricky, but there are resources out there. Static elements do not need ARIA if you use semantically correct HTML. Definitely look at examples and try to find multiple examples to make sure you are doing it right. Ask questions.

And the code… I created a snippet here: https://bitbucket.org/snippets/deibel/697RBy I’m happy to work with the PCJWG to incorporate my changes to their version. And these slides will be shared on the mailing list and added to the Systems page.