This document discusses making JavaScript applications more accessible. It begins by explaining why accessibility is important given the large number of people with disabilities. It then discusses common accessibility barriers with JavaScript, including some browsers not supporting JavaScript, lack of knowledge around WAI-ARIA practices, challenges with rich interactive applications using Ajax, and difficulty navigating with only a keyboard. The document provides tips for overcoming these barriers, such as using ARIA landmarks and attributes, semantic HTML, and skip navigation links. The overall message is that accessibility and JavaScript can coexist when the proper techniques are applied.

2. Summary
Throughout history, JS has been pointed out as the villain when the matter is
accessible websites.
By presenting some tricks and techniques, we plan to provoke this
discussion among developers and show that Accessibility and JS may live
together, as long as you take the right steps.
Accessibility and JS: side-by-side

3. Overview
● Why Should I invest on Accessibility?
● What is Accessibility?
● Who needs Accessibility?
● Essential things about the documentation
● User Agents: Do you know them?
● Barriers between Accessibility and JavaScript
● The great secret of accessible applications

4. #1
Why Should I invest on
Accessibility?

5. According to UN
650 Million
have some kind of disabilities
Many people around the world

6. In Brazil are over
According to IBGE
45.6 Million
people could be using your application.

7. Business opportunity
Who wouldn´t wanted to have
23%
of a population as possible clients?

8. The world cannot be excluded from great minds

9. When we talk about accessibility

10. #2
What is Accessibility?

11. It´s basically create or turn it accessible
for the largest number of users, mainly
for those with special needs
What would be an accessible application?
Anything isn’t enough
accessible that
couldn’t be improved

12. New accessibility
Passive
Robotic
Dependent
Impotent
Able
Active
Independent
Engajed

13. #3
Who needs accessibility?

14. Who needs accessibility?

15. Who needs accessibility?
Videos with subtitles

16. #4
Essential things about the
documentation

17. • W3C (World Wide Web Consortium)
• WAI (Web Accessibility Initiative)
• WCAG (Web Content Accessibility
Guidelines)
• WAI-ARIA(Accessible Rich Internet
Applications)
Alphabet soup
• ATAG (Authoring Tool
Accessibility Guidelines)
• UAAG(User Agent Accessibility
Guidelines)
• eMAG (Brazil´s e-gov model of
accessibility)
Most part of the material is produced by W3C and by institutions interested on
internet development as a whole. The idea is to have internet for all people.

18. Robust
Understandable
Operable
Perceivable
WCAG 4 Basic principles

19. WCAG #4.1 Perceivable
● Distinguishable information
● Text Alternatives
● Adaptable
● Time-based Media

20. WCAG #4.2 Operable
● Navigable
● Keyboard Accessible
● Seizures
● Enough Time

21. WCAG #4.3 Understandable
● Readable
● Predictable
● Input Assistance

22. WCAG #4.4 Robust
Compatible with different
User Agents

23. #5
Users Agents:
Do you know them?

24. User agents could be guide dogs

25. User agents could be web browsers

26. ...But usually Screen Readers

27. Screen Readers usage
WebAIM 2014

28. Mobile Screen Reader usage

29. We have to teach
We need to get connected
The user agents how to speak
Content
Presentation
Interactivity

30. #6
Barriers between
Accessibility and JavaScript

31. Accessibility Barriers
According to the University of Minnesota
● Some browsers may not support JavaScript or may have JavaScript
processing disabled.
● Users may be unaware of dynamically changing page content.
● Some AJAX features (widgets) may be difficult or impossible to navigate
using a keyboard alone.
● Some browsers and browser versions may not support AJAX.
● Some browsers and browser versions may not support ARIA standards.
● Some adaptive Technologies may not support AJAX and ARIA.

32. Accessibility Barriers
According to the University of Minnesota
● Some browsers may not support JavaScript or may have JavaScript
processing disabled.
● Users may be unaware of dynamically changing page content.
● Some AJAX features (widgets) may be difficult or impossible to navigate
using a keyboard alone.
● Some browsers and browser versions may not support AJAX.
● Some browsers and browser versions may not support ARIA standards.
● Some adaptive Technologies may not support AJAX and ARIA.
Summed up in four major problems
01. Browsers do not support JavaScript or it is disabled
02. Developers lack of knowledge in WAI-ARIA practices
03. Rich applications using dynamic content with Ajax
(Asynchronous Javascript and XML)
04. Difficulty or impossibility to navigate using a keyboard

33. #6.1
Browsers Don’t Support
JavaScript

34. Browsers Support JavaScript
According to WebAIM 2014, over 97% of screen readers
support and have javascript enabled
97,6%
Enabled
2,4%
Disabled

35. People use JavaScript and don´t know it!

36. Fallback strategies to others 2.4%
Provide alternative accessible controls that do not require script processing

37. A good idea for fallback strategies
Detect Features Instead of Browsers
function registerEvent( sTargetID, sEventName, fnHandler )
{
var oTarget = document.getElementById( sTargetID );
if ( oTarget != null )
{
if ( oTarget.addEventListener ) {
oTarget.addEventListener( sEventName, fnToBeRun, false );
} else {
var sOnEvent = "on" + sEventName;
if ( oTarget.attachEvent )
{
oTarget.attachEvent( sOnEvent, fnHandler );
}
}
}
}

38. #6.2
Developers lack of knowledge
in WAI-ARIA practices

39. What is WAI-ARIA
Accessible Rich Internet Applications (ARIA)
defines ways to make Web content and Web
applications (especially those developed with
Ajax and JavaScript) more accessible to
people with disabilities

40. WAI-ARIA Workflow

41. The jQuery creator says
ARIA isn’t just a pipe
dream of functionality,
It’s implemented!
John Resig

42. Use semantic and Landmarks ARIA
The language your
browser likes
to speak!

43. #6.3
Rich Internet Applications
With Ajax

44. Asynchronous Javascript and XML
Ajax is a technique for developing
interactive Web Applications
Updating of Web content without
refreshing the whole page
Every modern applications use it

45. Ajax and Accessibility
aria-live=”polite”
How polite the live area is?
The default is ‘polite’ – in that it waits
until all forms of user interaction have
been completed before describing the
updates to the user.
aria-relevant=”additions removals”
Only notify the user about new node additions and removals.
This will give us the appropriate level of updates to make this
possible.
aria-describedby=”users-desc”
A pointer to the element that describes the contents of
the live area. If the user wishes to know more about
what the contents of the field represent this element
can be read to them.

46. ARIA Live Regions

47. #6.4
Difficulty or impossibility to
navigate using a keyboard

48. Navigations and menus
Users that can´t or don´t want to use the mouse
could use keyboard to navigate on the application!

49. Insert in the link description
On the description we should avoid generic names such as “click here”, “download”
Write texts that make sense. Even when the monitor is turned off!
Preferred
Avoid

50. Jim Thatcher
pioneering
Using Links, #hashtags and
some IDs we could link and
navigate in the whole page!
Skip navigation 1998

51. Skip navigation visual focus

52. Skip navigation focus

53. Think beyond the mouse

54. Semantic menu and ARIA

55. Show and hide sub-menus

56. #7
The great secrets of
accessible applications

57. Accessibility menu

58. Font size control

59. High and low contrast

60. The WEB creator says
Take the Standards to
Keep the Web Free!
Tim Berners-Lee

61. Complementing Tim
ARIA and Interactive design too!
Felipe Albuquerque

62. Special thanks to
felipealbuquerque.com
fa@cesar.org.br
@felipedeolinda
Felipe de Albuquerque
Ask me here or by