1. Hans Hillen (TPG) Steve Faulkner (TPG) Karl Groves (TPG) Billy Gregory (TPG)

2.  Keyboard and Focus Management Keyboard and Focus Management  Form Validation Form Validation  Mode Conflicts Mode Conflicts  Solutions, Workarounds and Considerations Solutions, Workarounds and Considerations 03 / 18 / 14Accessibility of HTML5 and Rich Internet Applications - CSUN 20142

3. 03 / 18 / 14Accessibility of HTML5 and Rich Internet Applications - CSUN 20143

4. Problem:  Images, divs, spans etc. are not standard controls with defined behaviors o Not focusable with keyboard o Have a default tab order o Behavior is unknown Solution:  Ideally: Use native focusable HTML controls o,,, etc.  Or manually define keyboard focus and behavior needs 4Accessibility of HTML5 and Rich Internet Applications - CSUN 201403 / 18 / 14

5.  Reachability: Moving keyboard focus to a widget o Through tab order Native focusable controls or tabindex=“0” o Through globally defined shortcut o By activating another widget  Operability: Interacting with a widget o All functionally should be performable through keyboard and mouse input 03 / 18 / 14Accessibility of HTML5 and Rich Internet Applications - CSUN 20145

6.  To be accessible, ARIA input widgets need focus o Use natively focusable elements, such as,, etc o Add ‘tabindex’ attribute for non focusable elements, such as,, etc. Tabindex=“0”: Element becomes part of the tab order Tabindex=“-1” (Element is not in tab order, but focusable) o For composite widgets (menus, trees, grids, etc.), use a “roving tabindex”: Every widget should only have 1 stop in the tab order. Dynamically keep track where your widget’s current tab stop (active part) is: o Alternative for tabindex: ‘aria-activedescendant=“ ” Focus remains on outer container AT perceives element with the specified ID as being focused. You must manually highlight this active element, e.g. With CSS 03 / 18 / 14Accessibility of HTML5 and Rich Internet Applications - CSUN 20146

7.  Every widget needs to be operable by keyboard. common keystrokes are: o Arrow keys o Home, end, page up, page down o Enter, space o ESC  Mimic the navigate in the desktop environment o ARIA Best Practices: http://www.w3.org/WAI/PF/aria-practices/http://www.w3.org/WAI/PF/aria-practices/  Always manage and keep track of your focus. Never let it get lost. 7Accessibility of HTML5 and Rich Internet Applications - CSUN 201403 / 18 / 14

8.  The ability to skip content is crucial for both screen reader and keyboard users  Skip links are out of date, out of fashion and often misused o But keyboard users still need to be able to skip  Other alternatives for skipping: o Collapsible sections o Consistent shortcuts (e.g. a shortcut that moves focus between panes and dialogs) o Custom focus manager that allows the user to move focus into a container to skip its contents 03 / 18 / 14Accessibility of HTML5 and Rich Internet Applications - CSUN 20148

9. 03 / 18 / 14Accessibility of HTML5 and Rich Internet Applications - CSUN 20149

10.  You can use ARIA to make your form validation easier to manage. o aria-required & aria-invalid states o Role="alert" to flag validation errors immediately  Use validation summaries invalid entries easier to find o Use role=“group” or Role="alertdialog" to mark up the summary o Link to corresponding invalid controls from summary items o Use different scope levels if necessary  Visual tooltips: Useful for validation messages and formatting instructions o Tooltips must be keyboard accessible o Tooltip text must be associated with the form control using aria-describedby  Provide both inline and form wide feedback 03 / 18 / 14Accessibility of HTML5 and Rich Internet Applications - CSUN 201410

12.  Developers often use links as (icon) buttons o Side effect: screen reader will announce them as a link, not a button  This can be made accessible by setting role="button" o Screen reader announces link as button now, but also provides hint for using a button ("press" space to activate”) Screen reader lies: Links work through the Enter key, Space will scroll down the page o To make sure JAWS is not lying, you'll have to manually add a key event handler for the Space key. refresh 03 / 18 / 14Accessibility of HTML5 and Rich Internet Applications - CSUN 201412

13. 03 / 18 / 14Accessibility of HTML5 and Rich Internet Applications - CSUN 201413

14.  Screen readers normally browse in ‘virtual mode’ o Navigates a virtual copy of the web page o Intercepts all keystrokes for its own navigation (e.g. ‘H’ for heading navigation)  For dynamic Web apps, virtual mode may need to be turned off o Interactive widgets need to define the keystrokes themselves o Content needs to be live, not a virtual copy o Automatically switches between virtual and non-virtual mode  role=“application” o Screen reader switches to non-virtual for these elements o Must provide all keyboard navigation when in role=“application” mode o Screen readers don’t intercept keystrokes then, so typical functions will not work 14Accessibility of HTML5 and Rich Internet Applications - CSUN 201403 / 18 / 14

15.  For apps with ‘reading’ or ‘editing’ sections o A reading pane in an email client o Screen reader switches back to virtual mode, standard ‘web page reading’ shortcuts work again o Read / edit documents in a web application  Banner, complementary, contentinfo, main, navigation, search & form  When applied to a container inside an application role, the screen reader switches to virtual mode. 15Accessibility of HTML5 and Rich Internet Applications - CSUN 201403 / 18 / 14

16.  People that depend on assistive technology often: o Expect to be able to tab through all interactive elements o Expect virtual mode to work o Expect web content to be like it was in the late 90's: Simple page loads, no dynamic changes Simple Keyboard navigation: Tab, Enter, some times arrow keys  WAI – ARIA is meant for "Application UI's" o Requires virtual mode to be disabled o Requires custom shortcuts o Content can update dynamically Accessibility of HTML5 and Rich Internet Applications - CSUN 20141603 / 18 / 14

17.  How do you convey this different navigation style to screen reader users? o Modern screen readers have "auto-forms" mode (virtual mode is automatically turned off where applicable o Screen readers will provide basic instructions for interactions o Less experienced users will likely be confused  Sighted keyboard users do not get any instructions at all Accessibility of HTML5 and Rich Internet Applications - CSUN 20141703 / 18 / 14

18.  A tab list widget: o Web 1.0: Tab through every tab in the list o Web 2.0: Tab list takes up one tab stop, arrow keys are used for switching  Which one is correct?  What will the end user expect? Accessibility of HTML5 and Rich Internet Applications - CSUN 20141803 / 18 / 14

19. Accessibility of HTML5 and Rich Internet Applications - CSUN 201419

20.  Use role="dialog", combined with: o Aria-labelledby (for dialog title) o Aria-describedby (for dialog message text)  Focus management o When dialog opens, focus should move to first focusable element inside the dialog o Focus should "wrap" inside dialog and be contained by it. o For modal dialogs: No keyboard access with background content should be possible o For non modal dialogs: provide shortcut to switch between dialog and main page o Support closing dialogs using buttons and Escape key o When the dialog closes, focus should be placed back on a logical element, e.g. the button that triggered the dialog.  For modal dialogs: prevent virtual navigation to background using aria-hidden="true"  If dialog supports moving or resizing, these features must be keyboard accessible Accessibility of HTML5 and Rich Internet Applications - CSUN 20142003 / 18 / 14

21.  According to the ARIA Best Practices document: o A dialog is a special type of "application window" o All content must be (associated with) keyboard accessible content. Regular static is content not allowed. o Virtual navigation by screen readers is not allowed  This works for simple dialogs… o But not for complex dialog content often found in real life projects, which may have a large amount of static content o To force support for virtual navigation, role=“document” can be wrapped around the dialog content, but it’s an ugly hack.  Focus management o For dialogs with a large amount of (scrollable) content, the first focusable element may be too far down. Moving focus to it would cause a lot of content to be skipped Accessibility of HTML5 and Rich Internet Applications - CSUN 20142103 / 18 / 14

22. Accessibility of HTML5 and Rich Internet Applications - CSUN 201422 For Your Information Close …

23. 03 / 18 / 14Accessibility of HTML5 and Rich Internet Applications - CSUN 201423 Start of dialog For Your Information Close … End of dialog

24. 03 / 18 / 14Accessibility of HTML5 and Rich Internet Applications - CSUN 201424

25.  Three types of hiding: 1. Hiding content visually and from AT: 2. Hiding content visually, but not from AT 3. Hiding content from AT, but not visually 03 / 18 / 14Accessibility of HTML5 and Rich Internet Applications - CSUN 201425

26.  Display: none; o Hides content both visually and from AT products o Only works when CSS is supported (by user agent, user, or AT product) o Only use to hide content that still ‘makes sense’ E.g. contents of a collapsible section o Do not use for content that provides incorrect information E.g. preloaded error messages that are not applicable at the moment, or stale content Instead, this content should be removed from the DOM completely 03 / 18 / 14Accessibility of HTML5 and Rich Internet Applications - CSUN 201426

27.  Hiding content off-screen will still make it available for screen readers, without it being visible  Useful to provide extra information to screen reader users or users that do not support CSS o E.g. add hidden headings, screen reader instructions, role & state info for older technology /* Old */.offscreen { position: absolute; left: -999em; } /* New */.offscreen { position: absolute !important; clip: rect(1px 1px 1px 1px); clip: rect(1px,1px,1px,1px); } 03 / 18 / 14Accessibility of HTML5 and Rich Internet Applications - CSUN 201427

28.  Sometimes developers want to hide content from screen readers, e.g.: o Duplicate controls o Redundant information that was already provided through semantic markup.  Difficult to achieve: o Role=“presentation” will remove native role, but content is still visible for AT products o Aria-hidden=“true” provides a solution: Not supported well in older technology 03 / 18 / 14Accessibility of HTML5 and Rich Internet Applications - CSUN 201428

29. A Small Font 03 / 18 / 14Accessibility of HTML5 and Rich Internet Applications - CSUN 201429  Supported by the latest versions of major browsers and assistive technology.  Use with care: only for redundant/decorative content  NEVER use directly on focusable elements

30. 03 / 18 / 14Accessibility of HTML5 and Rich Internet Applications - CSUN 201430

31.  still alive and kicking o In HTML5 it’s allowed to nest headings  Summary attribute obsolete in HTML5 Animals Name Age Species... 03 / 18 / 14Accessibility of HTML5 and Rich Internet Applications - CSUN 201431

32.  Some developers will use multiple HTML elements to create one single grid. For example: o One for the header row, one for the body rows o One for every single row  Why? Because this is easier to manage, style, position, drag & drop, etc.  Screen reader does not perceive one single table, but it sees two ore more separate tables o Association between column headers and cells is broken o Screen reader's table navigation is broken 03 / 18 / 14Accessibility of HTML5 and Rich Internet Applications - CSUN 201432

33.  If using a single table is not feasible, use ARIA to fix the grid structure as perceived by the screen reader o Use role="presentation" to hide the original table elements form the screen readers o Use a combination of "grid", "row", "gridcell", "columnheader" roles to make the screen reader see one big grid. 03 / 18 / 14Accessibility of HTML5 and Rich Internet Applications - CSUN 201433

34.  Using ARIA to create a correct grid structure Dog Names Cat Names Cow names Fido Whiskers Clarabella 03 / 18 / 14Accessibility of HTML5 and Rich Internet Applications - CSUN 201434

35. 03 / 18 / 14Accessibility of HTML5 and Rich Internet Applications - CSUN 201435

36.  Some widgets use scrolling or animation to "slide" content into view o Example: a carousel widget: A long list of items, of which only a few are visible at a time o Example: A table that only shows a few columns at a time, and can be scrolled horizontally through "next" and "previous" buttons.  Content that slides into view is often not hidden properly, but "clipped" through overflow:hidden styles o Content is visually hidden, but still part of the tab order and (unintentionally) reachable to keyboard users 03 / 18 / 14Accessibility of HTML5 and Rich Internet Applications - CSUN 201436

37.  When content is scrolled out of view, ensure that it's not reachable to keyboard users  To do this, the "visibility: hidden" style is often easiest to use: o When content is scrolled out of view, set visibility: hidden o Before content is about to be scrolled into view, set visibility: visible o Use "visibility: hidden" over "display: none" to maintain the content's layout, which is often needed for the scrolling / animation to function correctly 03 / 18 / 14Accessibility of HTML5 and Rich Internet Applications - CSUN 201437

38. 03 / 18 / 14Accessibility of HTML5 and Rich Internet Applications - CSUN 201438

39.  When Windows High Contrast Mode is enabled, the following will happen: o Background and foreground colors are overridden o Background images are removed  Custom user style sheets often apply similar changes  UI libraries often uses background images for icons, which means these icons become invisible Accessibility of HTML5 and Rich Internet Applications - CSUN 20143903 / 18 / 14

40.  It's possible to detect the effects of high contrast mode or a custom stylesheet using scripting: o On page load, create an off screen div element, assign border and background styles to it, and inspect computed styles to see if they are overridden  This detection can be used to "fix" issues related to HC mode, e.g.: o Unhide hidden text to replace background images  Font icons are great for high contrast mode, but: o Not supported on all devices o Break easily when custom user stylesheet overrides font-family “Invisible font” solution is a promising workaround for this issue 03 / 18 / 14Accessibility of HTML5 and Rich Internet Applications - CSUN 201440

41.  Calling all AT users, QA testers, web developers, vendors, and general accessibility enthusiasts  Find and report AT Bugs  Track us on Twitter #TPGBB 03 / 18 / 14Accessibility of HTML5 and Rich Internet Applications - CSUN 201441

42.  Thursday, March 20th  5.30pm to 6.30pm  Suite 3233, Harbor tower, Manchester Grand Hyatt 03 / 18 / 14Accessibility of HTML5 and Rich Internet Applications - CSUN 201442

43.  Questions?  Additional Topics?  Course Material: http://www.paciellogroup.com/training/CSUN2014 http://www.paciellogroup.com/training/CSUN2014 03 / 18 / 14Accessibility of HTML5 and Rich Internet Applications - CSUN 201443