Javascript Framework Acessibiliity Review

ACCESSIBILITY REVIEW
@AIMEE_MAREE
JAVASCRIPT FRAMEWORKS

WHAT DOES ACCESSIBILITY
MEAN?
Elephant in the Room
JS FRAMEWORKS AND ACCESSIBILITY - @AIMEE_MAREE JSSYD MEETUP

WHAT DOES ACCESSIBILITY MEAN FOR ME,
▸ Access the application or website with increased font-size
▸ For video an option to use captions
▸ Option to read out content on the screen via audio at
times when needed
▸ Allows for a high zoom in factor for areas of the screen
▸ Creation of new assistive devices to enhance my families
life and my own

WHAT DOES ACCESSIBILITY MEAN FOR YOU?
▸ Humans can access the information via assistive
technologies such as Screen Readers
▸ Captions can be displayed on video
▸ As you age you can still read the text on the screen
▸ Low bandwidth users can access your website or app
▸ People on all types of devices can access your website not
just iPhone or Android?

ACCESSIBILITY IS ABOUT
PEOPLE.
We The People

JS FRAMEWORKS AND ACCESSIBILITY
ENABLING PEOPLE TO BE ABLE TO PARTICIPATE

THE MODERN DAY WEB IS
BUILT ON JAVASCRIPT
FRAMEWORKS
World Wide Web

BUT JAVASCRIPT CAN’T BE
MADE ACCESSIBLE?
Myth Maker

BUT THE DOM HAS A WEB API
AND HTML ELEMENTS ARE
ACCESSIBLE?
WCAG Standards

I WRITE JAVASCRIPT NOT
HTML!
Someone silly programmer

JAVASCRIPT AND HTML THE NEEDED DUO
▸ We still need HTML and CSS to layout a webpage
▸ Screen Readers and other tools look for HTML native elements
▸ JS Frameworks use javascript to inject HTML onto the webpage
▸ People like JS Frameworks they are client rendered and render quickly
▸ It can depend on the framework? Some frameworks have Aria calls
built into their components, some make more use of native elements.
▸ So I don't have to worry about HTML then? Well its JS yes, but your
still injecting HTML code and that is what needs to be accessible.

SOME KEY ISSUES WITH JS FRAMEWORKS AND ACCESSIBILITY
▸ Custom html elements that have no state, roles, properties so
the developer needs to give it this information by using aria
▸ Overuse of Aria, this leads to heavy use of aria in order to
communicate the purpose of the element
▸ Control of tab focus for keyboard is problematic when your
rebuilding the DOM needs a deeper level of focus
▸ Misuse of Aria-live states to announce dynamic areas to
Screen readers leads to a very verbose experience

BUT WE CAME FOR AN
OVERVIEW OF JS
FRAMEWORKS?
The Presenter

TEXT
MODERN DAY JS FRAMEWORK PROBLEMS A PLENTY
▸ New Frameworks popping up all over the place
▸ Retroﬁtting Accessibility is hard work
▸ Chasing the right framework can save you alot of time and
headaches
▸ Size of community can matter with documentation and
larger teams to focus on accessibility
▸ You will generally always be using custom elements so you
will need to learn and read up on ARIA standards

ANGULAR AND A11Y
Johnny Appleseed

ANGULAR AND A11Y
▸ Allows you to create custom HTML elements so you MUST
add aria tags to establish role, state, properties
▸ Has ngAria initiative that enables common ARIA attributes
to be easily used on elements
▸ Has community focused people on the core team who are
experienced and passionate about a11y more mature
framework which means alot of examples on the web
▸ Uses Google Material Design approach

EMBER AND A11Y
Johnny Appleseed

EMBER AND A11Y
▸ Has role built into native components which can be modiﬁed
▸ Need to add speciﬁc calls in components for tabindex,
ariaRole, aria-label, keyDown
▸ Works on web components concepts not yet implemented
across all browsers had to create a similar experience for
Screen Readers

REACT AND A11Y
Johnny Appleseed

REACT AND A11Y
▸ Has its own accessibility API similar to Android and iOS
▸ Advance set of Aria features built into components
▸ Has react a11y tool to perform an automated a11y check
▸ Mature framework that has an a11y initiative, wide
developer tool set and tutorials around web accessibility

POLYMER AND A11Y
Johnny Appleseed

POLYMER AND A11Y
▸ Has common Aria calls and design concepts built into the
native framework elements
▸ Uses Google Material Design approach
▸ Early Framework and works on web components concepts
not yet implemented across all browsers had to create a
similar experience for Screen Readers

THE KEY PROBLEMS ARE
INHERENT IN THEM ALL NO
ONE FRAMEWORK IS QUEEN
Johnny Appleseed

ALL FRAMEWORKS SAME PROBLEMS
▸ Lack of use of Native HTML elements
▸ Enforce use of custom elements and DOM declarations
▸ Loss of Focus order due to DOM restructuring
▸ Overuse of Aria tags - Developer must understand
expected element interactions
▸ Accessibility as an after thought

SO WHATS THE TAKE AWAY
HERE?
Audience

ACCEPT THE KEY PITFALLS
▸ Introduction of custom HTML elements means more care
and concern is needed to be taken to ensure Aria roles
and states are communicated to the DOM
▸ Working with Shadow DOM, Shady DOM, Polyﬁlls
▸ Sometimes its impossible to use Native HTML Elements
(See polymer table bug)
▸ Focus on the leading, bleeding edge technology means
accessibility is an after thought and retro ﬁtted

CROSS BROWSER CODE AND
CROSS SCREEN READER?
Johnny Appleseed

SCREEN READERS AND OS
▸ Mac OSX Voice Over Safari/Firefox
▸ Mac OSX NVDA Safari/Firefox
▸ Mac OSX JAWS Safari/Firefox
▸ iOS Voice Over
▸ Windows Phone Narrator
▸ Windows JAWS Internet Explorer/FireFox/Chrome
▸ Windows NVDA Internet Explorer/FireFox/Chrome
▸ Linux ORCA Firefox/Chromium
▸ … the list keeps growing and the user experience varies greatly

SO WHERE DO I START? ARE
THERE CROSS READER TIPS?
sensible developer

CROSS SCREEN READER COMPATIBILITY
▸ There is a Browser API for a11y, read up on Wai-ARIA and when
testing create the component in native HTML outside of the JS
Framework to compare your custom elements behaviour to
▸ There is no standard for Screen Readers apart from Aria tags and
Native elements but this can and often is interpreted differently
by Screen Readers
▸ Native elements will create the most similar experience across all
▸ When your working with Shadow DOM, Shady DOM and Polyﬁlls
your DOM element ordering can be different

UNDERSTAND ARIA

SOME QUICK CODE
APPROACHES TO PRACTICE
The Presenter

SOME CODE APPROACH TAKEAWAYS
▸ Use native HTML elements where you can
▸ And tabIndex=0 to custom elements not in the tab order and also
add a focus CSS style
▸ add alt tags and captions to images used to convey information
▸ manage your focus order and check cross browser and screen reader
▸ understand the interaction of the element, if its a button is the
interaction expected a space key press for Aria?
▸ Use your landmarks correctly and never apply on the body tag

CODE APPROACHES…. CONTINUED
▸ If native inputs can’t be used (with good reason), create
custom checkboxes with role=checkbox, aria-checked, aria-
disabled and aria-required, and wire up keyboard events.
▸ Custom elements need to tell the dom for a11y about their
ROLE, STATE and Properties
▸ add FOCUS if needed TabIndex=0 only do not increment
▸ TabIndex=0 will mean that your custom element follows
the order of structure that the DOM sees

BUILD ACCESSIBILITY INTO UNIT TESTS
▸ Watched ARIA properties
▸ Keyboard operability
▸ Text alternatives
▸ Semantics

GO FORTH AND MAKE THE WEB
MORE ACCESSIBLE…
The Presenter

Javascript Framework Acessibiliity Review

More Related Content

What's hot

Viewers also liked

Similar to Javascript Framework Acessibiliity Review

More from Aimee Maree

Recently uploaded

Javascript Framework Acessibiliity Review