Presented at Free Software and Open Source Symposium, 2013. Understand real challenges for building accessible web applications, and learn how to effectively design boundless User Interfaces. It presents a potentially innovative concept, a new paradigm for designing User Interfaces being oriented by accessibility. Therefore, it discusses a new perspective that can affect creative and development processes, the design and development of rich interactive applications truly applying accessibility principles, which is highly desirable, commonly difficult, and rarely accomplished.

1. Accessibility-Oriented
Paradigm for Designing UI
Ystallonne Alves

2. Ystallonne Alves
Interactive Web Developer
2 | 43

3. Agenda

Accessibility concept


Guidelines for
accessibility
Standards-compliant
markup and CSS

Successful projects
showcase

Final thoughts

Q&A

Assistive Technology

Accessibility testing
and tools
3 | 43

4. Accessibility concept
4 | 43

5. Accessibility concept

Allowing individuals with disabilities to use
applications.

Includes all disabilities that affect access:

Visual

Learning

Auditory

Cognitive

Speech

Neurological

Physical
5 | 43

6. Accessibility concept

It is NOT the same as: Usability


Designing applications to be more effective, efficient,
satisfying for all
It is NOT the same as: Device Independence

Small screen devices

Older browsers
Accessibility addresses issues that put individuals with
disabilities at a disadvantage
6 | 43

7. Accessibility concept
Good News

There is no such thing
as inaccessible
Bad News

There is no such thing
as accessible
7 | 43

8. Accessibility concept

Range of accessibility

You cannot make everything accessible to everyone

You can make content more accessible to more people

Different standards result in greater or less
accessibility
8 | 43

9. Accessibility concept
Benefits

Provides equal opportunity

More access to information

More opportunity for interaction

Makes applications usable considering elements
such as: eyes, ears, motor control, perception of
color, and input devices
9 | 43

10. Accessibility concept
Difficulties

There are wide implementation differences between
browsers, platforms, and screen readers.

Older browsers and screen readers are not likely to
handle dynamic web applications.

No browser or screen reader has fully implemented
accepted standards.

There is no clear documentation on what is widely
supported in all tools.
10 | 43

11. Guidelines for accessibility
11 | 43

12. Guidelines for accessibility

World Wide Web Consortium (W3C): It develops web-related standards, the
best known of which is probably HTML. Several accessibility-focused standards
have been produced by W3C, among them are:

Accessible Rich Internet Applications (ARIA): defines a technology for
making dynamic web applications more accessible.

Web Content Accessibility Guidelines (WCAG): guidelines for creating
accessible web sites.

Authoring Tool Accessibility (ATAG): guidelines for developing authoring
tools that encourage and support authors to create accessible websites.

User Agent Accessibility Guidelines (UAAG): guidelines for developers of
browsers, media players, etc. that facilitate accessible use.
12 | 43

13. Guidelines for accessibility

AODA

The Accessibility for Ontarians with Disabilities Act (AODA) sets
accessibility requirements in several areas, including information
technology.

Inclusive design in Canada is in part driven by a background of antidiscrimination law such as the Canadian Charter of Rights and Freedoms
and the Canadian Human Rights Act. The Common Look and Feel policy of
the Canadian Government requires its websites to meet a number of
accessibility requirements based on WCAG.
13 | 43

14. Guidelines for accessibility

U.S. Section 508, and U.S. ADA standards

Internationally, many other countries also have
legislation and policies regarding accessibility. In the
United States, the Americans with Disabilities Act
(ADA) and Section 508, which requires accessibility to
be considered in government purchasing, have been
important incentives to inclusive design.
14 | 43

15. Assistive Technology
15 | 43

16. Assistive Technology

Screen readers and magnifiers


Refreshable Braille display


Blind and deaf
Captioning software


Blind and visually impaired
Deaf
© Google IO
Voice recognition software, switches and pointer sticks, and
touch screens

Motor impairments
16 | 43

17. Assistive Technology

Screen readers

JAWS, Job Access With Speech (Windows)

NVDA, NonVisual Desktop Access (Windows)

Orca (Linux)

VoiceOver (Mac OS)

ChromeVox (Chrome OS)
17 | 43

18. Assistive Technology

Technology used differently

Keyboard navigation

Browser or system font size

Browser window size

Color settings

Use style sheets
18 | 43

19. Accessibility testing and tools
19 | 43

20. Accessibility testing and tools

Accessibility Developer Tools

ChromeVox
A screen reader for blind users

ChromeVis
A magnifier for low-vision users

ChromeShades
An accessibility testing tool for developers

All of these extensions are open-source, available at:
google-axs-chrome.googlecode.com
20 | 43

21. Accessibility testing and tools

Accessibility Developer Tools
Category
Checks for
Labels and Alternative Content
Images and form fields are labeled
Keyboard Accessibility
Focusable UI controls
ARIA
Valid ARIA roles
Low-vision Accessibility
Foreground/background contrast ratio
Video Accessibility
Captions and fallback content
21 | 43

22. Accessibility testing and tools

Color testing

Contrast-A

http://www.dasplankton.de/ContrastA/
22 | 43

23. Accessibility testing and tools

Color Filter


Etre


http://colorfilter.wickline.org/
http://www.etre.com/tools/colourblindsimulator/
Sim Daltonism

http://michelf.ca/projects/sim-daltonism/
23 | 43

24. Accessibility testing and tools

AChecker (WCAG 1.0, Section 508, Stanca Act, BITV)


Wave (WCAG 1.0, Section 508)


http://achecker.ca/checker/
http://wave.webaim.org
Other tools suggested by W3C

http://www.w3.org/WAI/ER/tools/complete
24 | 43

25. Standards-compliant markup and CSS
25 | 43

26. Standards-compliant markup and CSS

One way to make your web app accessible is:

Basic HTML

Simple layout

Forms-based interaction

No JavaScript
26 | 43

27. Standards-compliant markup and CSS

On the other hand, an enhanced way to make your web
app accessible is:

Use clean HTML and use standard tags whenever
possible;

Manage focus;

Add key handlers; and

Add ARIA for screen readers.
27 | 43

28. Standards-compliant markup and CSS
Use clean HTML and use standard tags whenever possible

Do not use a generic div or span when there is another
HTML tag that is more semantically appropriate.
<span onclick="">...
<div onclick="">...

⇒
⇒
<a href="">...
<button onclick="">...
Native HTML5 links and controls are accessible by default:
<button>Click here</button>
<input type=range></input>
<textarea>Accessible website</textarea>
28 | 43

29. Standards-compliant markup and CSS
Use clean HTML and use standard tags whenever possible

Label images and form controls
<img src="chart.png" alt=“My description">
<label for="firstName">First name:<label>
<input type="text" id="firstName"/>

Use CSS for layout, make sure DOM order is logical.
29 | 43

30. Standards-compliant markup and CSS
Use clean HTML and use standard tags whenever possible

CSS3 Filters: apply color filters to everything, including
iframes, video, etc.
-webkit-filter: invert()
-webkit-filter: brightness(20%)
-webkit-filter: grayscale()
-webkit-filter: invert() contrast(80%)
30 | 43

31. Standards-compliant markup and CSS
Use clean HTML and use standard tags whenever possible

It is possible to invert all content on a page, including
images, simply applying the following CSS:
html {
-webkit-filter: invert();
}
31 | 43

32. Standards-compliant markup and CSS
Manage focus

Make custom interactive elements focusable with
tabindex:
<!-- Natural tab order -->
<div onclick="" tabindex="0">Clicky 1</div>
<!-- Custom tab order -->
<div onclick="" tabindex="7">Clicky 2</div>
<!-- Focusable but not in tab order -->
<div onclick="" tabindex="-1">Clicky 3</div>
32 | 43

33. Standards-compliant markup and CSS
Add key handlers

Custom controls should respond to keys like Enter, Space,
Arrows, Escape, etc. as appropriate.
<div id="replyIcon" tabindex="0" onclick="reply()"
onkeydown="return onReplyKeydown(event)">Reply</div>
function onReplyKeydown(event) {
// It executes when pressing Space or Enter
if (event.keyCode == 32 || event.keyCode == 13) {
reply();
}
33 | 43
}

34. Standards-compliant markup and CSS
Add ARIA for screen readers

ARIA (Accessible Rich Internet Applications), now part of
HTML5, allows you to build arbitrary custom controls and
make them accessible.

ARIA attributes provide semantic information to screen
readers that is normally conveyed visually.
34 | 43

35. Standards-compliant markup and CSS
Add ARIA for screen readers

Use the ARIA role attribute to indicate that a generic tag
is playing the role of a standard widget like a button:
<div tabindex="0" role="button">Send</div>

Use ARIA states and properties to add dynamic information
about the current state of an element:
<div tabindex="0" role="checkbox" aria-checked="true">
Include attachments </div>
35 | 43

36. Standards-compliant markup and CSS
Add ARIA for screen readers

Content that changes without a page refresh should be
identified as a live region.

Add ARIA live region attributes to dynamic content:
<span class='saving' aria-live='polite'>Saving...</span>

There are also certain ARIA roles which are considered
"live" by default:
<div role='alert'>Are you that you want to delete?</div>
36 | 43

37. Successful projects showcase
37 | 43

38. Successful projects showcase

Canadian Government


American Government


http://www.canada.ca/home.html
http://www.usa.gov/
Accessites

http://www.accessites.org/site/category/showcase
38 | 43

39. Final thoughts
39 | 43

40. Final thoughts

Recap: Formulating an Accessibility-Oriented Paradigm for
Designing UI
 Define target platform and audience
 Design UI outlines considering accessibility testing and
validation results
 Transform UI visual plans into a coded UI
 Develop with standards-compliant technology,
continuously executing accessibility-focused
progressive enhancements
40 | 43

41. Final thoughts

Accessible does not have to mean static, slow, and simple.
With just a bit more work, it is possible to deliver a
dynamic accessible experience and visually appealing UI.

The first step does not require any special tools or
expertise: just unplug your mouse.

Start experimenting other alternatives for interactivity.
41 | 43

42. Q&A
42 | 43

43. Thank you for your attention!
Ystallonne Alves
contact@Ystallonne.com
www.ystallonne.com
43 | 43