/
Accessibility of HTML5 and Rich Internet Accessibility of HTML5 and Rich Internet

Accessibility of HTML5 and Rich Internet - PowerPoint Presentation

pamella-moone
pamella-moone . @pamella-moone
Follow
388 views
Uploaded On 2017-08-23

Accessibility of HTML5 and Rich Internet - PPT Presentation

Applications Part 2 Hans Hillen TPG Steve Faulkner TPG 02 25 13 Accessibility of HTML5 and Rich Internet Applications CSUN 2013 1 In This Part Keyboard and Focus Management Labeling and Describing ID: 581369

accessibility html5 internet rich html5 accessibility rich internet applications csun 2013 aria role screen content reader keyboard table button

Share:

Link:

Embed:

Download Presentation from below link

Download Presentation The PPT/PDF document "Accessibility of HTML5 and Rich Internet" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.


Presentation Transcript

Slide1

Accessibility of HTML5 and Rich Internet Applications (Part 2)

Hans Hillen (TPG)Steve Faulkner (TPG)

02 / 25 / 13

Accessibility of HTML5 and Rich Internet Applications - CSUN 2013

1Slide2

In This Part:Keyboard and Focus ManagementLabeling and Describing

Live RegionsForm ValidationMode Conflicts

Fallback Solutions02 / 25 / 13Accessibility of HTML5 and Rich Internet Applications - CSUN 20132Slide3

Keyboard and Focus Management

02 / 25 / 13

Accessibility of HTML5 and Rich Internet Applications - CSUN 20133Slide4

The Problem with Custom ControlsProblem: Images, divs, spans etc.

are not standard controls with defined behaviorsNot focusable with keyboardHave a default tab orderBehavior is unknown

Solution:Ideally: Use native focusable HTML controls <a>, <input type=“image” />, <button>, etc.Or manually define keyboard focus and behavior needs4Accessibility of HTML5 and Rich Internet Applications - CSUN 201302 / 25 / 13Slide5

Keyboard Issues in a NutshellReachability: Moving keyboard focus to a widget Through tab orderNative focusable controls or tabindex

=“0”Through globally defined shortcutBy activating another widget Operability: Interacting with a widgetAll functionally should be performable through keyboard and mouse input

02 / 25 / 13Accessibility of HTML5 and Rich Internet Applications - CSUN 20135Slide6

Focus & Keyboard AccessibilityTo be accessible, ARIA input widgets need focus

Use natively focusable elements, such as <a>, <input />, etcAdd ‘tabindex’ attribute for non focusable elements, such as <span>, <div>, etc.

Tabindex=“0”: Element becomes part of the tab orderTabindex=“-1” (Element is not in tab order, but focusable)For composite widgets (menus, trees, grids, etc.):Every widget should only have 1 stop in the tab order.Keep track where your widget’s current tab stop is:Alternative for tabindex: ‘aria-activedescendant=“<idref>”Focus remains on outer containerAT perceives element with the specified ID as being focused.You must manually highlight this active element, e.g. With CSS

02 / 25 / 13

Accessibility of HTML5 and Rich Internet Applications - CSUN 2013

6Slide7

Keyboard HandlingEvery widget needs to be operable by keyboard. common keystrokes are:Arrow keys

Home, end, page up, page downEnter, spaceESCMimic the navigate in the desktop environmentDHML

Style Guide: http://dev.aol.com/dhtml_style_guide ARIA Best Practices: http://www.w3.org/WAI/PF/aria-practices/ 7Accessibility of HTML5 and Rich Internet Applications - CSUN 201302 / 25 / 13Slide8

Skipping MechanismsThe ability to skip content is crucial for both screen reader and keyboard users

Skip links are out of date, out of fashion and often misusedBut keyboard users still need to be able to skip

Other alternatives for skipping:Collapsible sectionsConsistent shortcuts (e.g. a shortcut that moves focus between panes and dialogs)Custom focus manager that allows the user to move focus into a container to skip its contents

02 / 25 / 13

Accessibility of HTML5 and Rich Internet Applications - CSUN 2013

8Slide9

Popup Dialogs and WindowsMore and more web apps use HTML based popup dialogs rather than actual browser windows/dialogs

Get a screen reader to perceive it properly using role="dialog"Dialogs should have their own tab orderFocus should "wrap"

For modal dialogs, it should not be possible to interact with the main page Prevent keyboard accessVirtual mode access can't be preventedFor non modal dialogs, provide shortcut to switch between dialog and main pageIf dialog supports moving or resizing, these features must be keyboard accessibleSupport closing dialogs using Enter (OK) or Escape (Cancel) keysFocus should be placed back on a logical element, e.g. the button that triggered the dialog.

02 / 25 / 13

Accessibility of HTML5 and Rich Internet Applications - CSUN 2013

9Slide10

Selection & EditingTrees, Lists, Grids can support single or multiple selectionMultiple selection must be keyboard accessible, for example:

Shift + arrow keys: contiguous selectionCtrl + arrow keys: move focus without selectionCtrl + space: Toggle focused item in selection (discontiguous selection)Editable grids need to support switching to edit mode by keyboard

02 / 25 / 13

Accessibility of HTML5 and Rich Internet Applications - CSUN 2013

10Slide11

Labeling and Describing02 / 25 / 13

Accessibility of HTML5 and Rich Internet Applications - CSUN 2013

11Slide12

Labeling in a NutshellAll of these must have an accessible name:Every interactive widgetComposite widgets (menu(bar), toolbar,

tablist, tree, grid)Groups, regions and landmarksBrowsers determines an element’s accessible name by checking the following :

aria-labelledbyaria-labelAssociated label (<label for=“myControl”>) or alt attributeText contentsTitle attributeOptionally, add an accessible description for additional info02 / 25 / 13Accessibility of HTML5 and Rich Internet Applications - CSUN 201312Slide13

Labeling And Describing Widgets (2)

Aria-labelledby=“IDREFS”

Value is one or more IDs of elements that identifiy the widget.The elements ‘aria-labelledby’ targets can be any kind of text based element, anywhere in the document.Add multiple Ids to concatinate label text:Multiple elements can label one widget, and one element can label multiple widgets. (example)Aria-describedby=“IDREFS”Similar to labelledby, except used for additional description, e.g. Form hints, instructions, etc.Aria-labelSimply takes a string to be used as label.

Quick and dirty way of making the screen reader say what you want.Very easy to use, but only supported in Firefox at the moment. <h2 id=“treeLbl”>My Folders</h2><p class=“hidden”>Each tree item has a context menu with more options</p><div role=“tree” aria-labelledby=“treeLbl” aria-describedby=“treeDesc”>...

02 / 25 / 13

Accessibility of HTML5 and Rich Internet Applications - CSUN 2013

13Slide14

Labeling containersContainers such as toolbars, dialogs, and regions provide context for their contents

When the user moves focus into the container, the screen reader should first announce the container before announcing the focused control

<div role="dialog" aria-labelledby="dialogTitle" aria-describedby="dialogDescription"> <h2 id="dialogTitle">Confirm</h2> <p id="dialogDescription"> Are you sure you want to do that? </p> <button>Yes</button> <button>No</button></div>

02 / 25 / 13

Accessibility of HTML5 and Rich Internet Applications - CSUN 2013

14Slide15

Labeling Tables<caption> still alive and kickingIn HTML5 it’s allowed to nest headingsSummary attribute obsolete in HTML5

<table> <caption> <h2>Animals</h2>

</caption> <tbody> <tr> <th scope="col" abbr="pet name">Name <th scope="col">Age</th> <th scope="col">Species</th> </tr> ... </tbody></table>02 / 25 / 13Accessibility of HTML5 and Rich Internet Applications - CSUN 201315Slide16

Live Regions02 / 25 / 13

Accessibility of HTML5 and Rich Internet Applications - CSUN 2013

16Slide17

ARIA Live RegionsProblem: content is updated dynamically on screen may not be apparent to screen reader users

No page refresh, no screen reader announcementChange is only announced by stealing focusUsers miss relevant informationUsers have to ‘search’ for updated page content

Solution: live regions indicate page updates without losing focusScreen readers announce change based on type of live regionChallenge: When should users be informed of the change? Ignore trivial changes: changing seconds in a clockAnnounce important changes immediately / as convenient02 / 25 / 13Accessibility of HTML5 and Rich Internet Applications - CSUN 201317Slide18

“Built In” Live RegionsRole=“alert” for one-time, high-priority notifications

Shown for a period of time, or until the cause of the alert is solvedBasic message, no complex contentThe element with the alert role does not need to be focused to be announced

Role=“alertdialog” is similar to alert, but for actual (DHTML) dialogs.May contain other widgets, such as buttons or other form fieldsDoes require a sub-element (such as a ‘confirm’ button) to receive focusLive regions ‘built into ‘ roles’role="timer", "log", "marquee" or "status“ get default live behaviorRole=“alert” implicitly sets live to assertive18Accessibility of HTML5 and Rich Internet Applications - CSUN 201302 / 25 / 13Slide19

How to Use Live RegionsIdentify which part (containing HTML element) is expected to be updated

To make it live, add ‘aria-live’ attribute with a politeness value:

Off (default): Do not speak this region Polite: Speak this region when the user is idleAssertive: Speak this region as soon as possible Choose whether entire region should be announced or just the part that changed:‘aria-atomic': true (all) or false (part)Add other attributes as necessary:aria-relevant: choose what to announce:Combination of ‘Additions’, ‘removals’, ‘text’, ‘all’aria-busy: indicate content is still updatingaria-labelledby, aria-describedby: label and describe regions

19Accessibility of HTML5 and Rich Internet Applications - CSUN 201302 / 25 / 13Slide20

Forms & Validation02 / 25 / 13

Accessibility of HTML5 and Rich Internet Applications - CSUN 2013

20Slide21

Forms & ARIAYou can used ARIA to make your form validation easier to manage.

aria-required & aria-invalid statesRole="alert" to flag validation errors immediatelyUse validation summaries invalid entries easier to find

Use role=“group” or Role="alertdialog" to mark up the summaryLink to corresponding invalid controls from summary itemsUse different scope levels if necessary Visual tooltips: Useful for validation messages and formatting instructionsTooltips must be keyboard accessible Tooltip text must be associated with the form control using aria-describedbyLive Regions: Use for concise feedback messages

02 / 25 / 13

Accessibility of HTML5 and Rich Internet Applications - CSUN 2013

21Slide22

Mode Conflicts 02 / 25 / 13

Accessibility of HTML5 and Rich Internet Applications - CSUN 2013

22Slide23

Role = ApplicationScreen readers normally browse in ‘virtual mode’Navigates a virtual copy of the web page

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

Interactive widgets need to define the keystrokes themselvesContent needs to be live, not a virtual copyAutomatically switches between virtual and non-virtual moderole=“application”Screen reader switches to non-virtual for these elementsMust provide all keyboard navigation when in role=“application” modeScreen readers don’t intercept keystrokes then, so typical functions will not work23Accessibility of HTML5 and Rich Internet Applications - CSUN 201302 / 25 / 13Slide24

Role = DocumentFor apps with ‘reading’ or ‘editing’ sections A reading pane in an email client

Screen reader switches back to virtual mode, standard ‘web page reading’ shortcuts work againRead / edit documents in a web application

Banner, complementary, contentinfo, main, navigation, search & formWhen applied to a container inside an application role, the screen reader switches to virtual mode.24Accessibility of HTML5 and Rich Internet Applications - CSUN 201302 / 25 / 13Slide25

Fall Back Solutions02 / 25 / 13

Accessibility of HTML5 and Rich Internet Applications - CSUN 2013

25Slide26

Role = PresentationRole=“presentation” overrides existing role

Useful to ‘hide’ default HTML roles from ATFor example: Hide layout tables by adding the role to the <table>

elementTextual content read by the screen reader but table is ignored02 / 25 / 13Accessibility of HTML5 and Rich Internet Applications - CSUN 201326Slide27

Fall back solution for dialogsIn IE, some versions of JAWS currently does not properly announce dialogs when moving focus into them

It's possible to provide a fallback solution for IE to fix this, using hidden fieldsets to apply the ARIA dialog markup to Hide

fieldset's padding, margin, and borderMove legend off-screen <fieldset role="dialog" aria-labelledby="dialogTitle" aria-describedby="dialogDescription"> <legend id="dialogTitle">Confirm</legend> <p id="dialogDescription"> Are you sure you want to do that? </p> <button>Yes</button> <button>No</button></fieldset>

02 / 25 / 13

Accessibility of HTML5 and Rich Internet Applications - CSUN 2013

27Slide28

Fallback solutions for link buttonsDevelopers often use links as (icon) buttons

Side effect: screen reader will announce them as a link, not a buttonThis can be made accessible by setting role="button"

Screen reader announces link as button now, but also provides hint for using a button ("press" space to activate)You lie! Links work through the Enter key, Space will scroll down the page To make sure JAWS is not lying, you'll have to manually add a key event handler for the Space key.<a role="button" onkeypress="handleKeyPress(event);">refresh</a>

02 / 25 / 13

Accessibility of HTML5 and Rich Internet Applications - CSUN 2013

28Slide29

Hiding ContentThree types of hiding:Hiding content visually and from AT:

Hiding content visually, but not from ATHiding content from AT, but not visually

02 / 25 / 13Accessibility of HTML5 and Rich Internet Applications - CSUN 201329Slide30

1. Hiding Content from AllDisplay: none;Hides content both visually and from AT productsOnly works when CSS is supported (by user agent, user, or AT product)

Only use to hide content that still ‘makes sense’E.g. contents of a collapsible section Do not use for content that provides incorrect informationE.g. preloaded error messages that are not applicable at the moment, or stale content

Instead, this content should be removed from the DOM completely02 / 25 / 13Accessibility of HTML5 and Rich Internet Applications - CSUN 201330Slide31

2. Hiding Content VisuallyHiding 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 CSSE.g. add hidden headings, screen reader instructions, role & state info for older technology

/* Old */.offscreen { position: absolute; left: -999em;}/* New */.ui-helper-hidden-accessible { position: absolute !important; clip: rect(1px 1px 1px 1px); clip: rect(1px,1px,1px,1px); }02 / 25 / 13Accessibility of HTML5 and Rich Internet Applications - CSUN 201331Slide32

3. Hiding Content From AT OnlySometimes developers want to hide content from screen readers, e.g.:Duplicate controls

Redundant information that was already provided through semantic markup. Difficult to achieve:Role=“presentation” will remove native role, but content is still visible for AT products Aria-hidden=“true” would be ideal, but:

Browsers handle aria-hidden differentlyIE does nothing FF exposes content but marks it as hiddenChrome does not expose content (i.e. truly hides it)02 / 25 / 13Accessibility of HTML5 and Rich Internet Applications - CSUN 201332Slide33

ARIA-HIDDEN <a href="#">

<span aria-hidden="true">A</span> <span class="HiddenText">Small Font</span>

</a>02 / 25 / 13Accessibility of HTML5 and Rich Internet Applications - CSUN 201333JAWS 14 and NVDA will honor aria-hidden in IE, Firefox and Chromeregardless of whether the browsers actually expose it!VoiceOver does not honor aria-hidden at this pointSlide34

Grids and Tables02 / 25 / 13

Accessibility of HTML5 and Rich Internet Applications - CSUN 2013

34Slide35

Fixing Incorrect Grid Structure (1)Some developers will use multiple HTML <table> elements to create one single grid. For example:

One <table> for the header row, one <table> for the body rowsOne <table> 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 tablesAssociation between column headers and cells is brokenScreen reader's table navigation is broken

02 / 25 / 13

Accessibility of HTML5 and Rich Internet Applications - CSUN 2013

35Slide36

Fixing Incorrect Grid Structure (2)If using a single table is not feasible, use ARIA to fix the grid structure as perceived by the screen reader Use role="presentation" to hide the original table elements form the screen readers

Use a combination of "grid", "row", "gridcell", "columnheader" roles to make the screen reader see one big grid.

02 / 25 / 13

Accessibility of HTML5 and Rich Internet Applications - CSUN 2013

36Slide37

Fixing Incorrect Grid Structure (3)Using ARIA to create a correct grid structure

<div role="grid">

<table role="presentation"> <tr role="row"> <th role="columnheader">Dog Names</th> <th role="columnheader">Cat Names</th> <th role="columnheader">Cow names</th> </tr> </table> <table role="presentation"> <tr role="row"> <td role="gridcell">Fido</td> <td role="gridcell">Whiskers</td> <td role="gridcell">Clarabella</td> </tr>

</table> </div>

02 / 25 / 13

Accessibility of HTML5 and Rich Internet Applications - CSUN 2013

37Slide38

Anything Else?Questions? Additional Topics?Course Material: http://www.paciellogroup.com/training/CSUN2013

02 / 25 / 13

Accessibility of HTML5 and Rich Internet Applications - CSUN 201338