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

▸ Retrofitting 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 modified

▸ Need to add specific 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, Polyfills

▸ 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 fitted

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 Polyfills 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


Date post:	14-Apr-2017
Category:	Internet
Upload:	aimee-maree-forsstrom
View:	72 times
Download:	1 times