Recommended
More Related Content
Viewers also liked
Viewers also liked (11)
Similar to Choosing and Accessible UI Framework
Similar to Choosing and Accessible UI Framework (20)
Recently uploaded
Recently uploaded (20)
Choosing and Accessible UI Framework
- 1. CHOOSING AN ACCESSIBLE UI FRAMEWORK
- 2. 2CONTACT Choosing an Accessible UI Framework Gerard K. Cohen Wells Fargo, Wholesale Technology Services email:// gerardkcohen@gmail.com twitter:// @gerardkcohen Kevin Kalahiki email:// kkalahiki@gmail.com
- 4. HOW DO YOU KNOW WHICH ONE IS ACCESSIBLE?
- 6. 6TOPICS Choosing an Accessible UI Framework FORMS DIALOGS DOCUMENTATION TABS
- 7. 7CRITERIA Choosing an Accessible UI Framework KEYBOARD NAVIGATION/ FOCUS INDICATION ARIA PROPER LABELS/ DESCRIPTIONS COLOR CONTRAST
- 9. FORMS
- 10. 10FORM CRITERIA Choosing an Accessible UI Framework FOCUS INDICATION ERROR VALIDATION PROPER LABELS/ GROUPING COLOR CONTRAST
- 11. TABS
- 12. 12TABS CRITERIA Choosing an Accessible UI Framework FOCUS INDICATION ARIA KEYBOARD INTERACTION COLOR CONTRAST
- 13. 13TABS KEYBOARD INTERACTION Choosing an Accessible UI Framework LEFT/ UP FOR PREVIOUS TAB ARROW KEYS SHOULD CYCLE TAB KEY FOCUSES ACTIVE TAB RIGHT/ DOWN FOR NEXT TAB
- 14. 14TABS ARIA Choosing an Accessible UI Framework STATES: ARIA-SELECTED ROLES: TABPANEL, TABLIST, TAB PROPERTIES: ARIA-CONTROLS
- 15. DIALOGS
- 16. 16DIALOG CRITERIA Choosing an Accessible UI Framework FOCUS INDICATION ARIA KEYBOARD INTERACTION COLOR CONTRAST
- 17. 17DIALOG ARIA Choosing an Accessible UI Framework ROLES: DIALOG, ALERTDIALOG PROPERTIES: ARIA-LABEL, ARIA-LABELLEDBY
- 18. SOLUTIONS
- 19. FORMS
- 20. 20FORMS SOLUTION Choosing an Accessible UI Framework GROUP RELATED FIELDS WITH FIELDSET/ LEGEND EXPLICITLY ASSOCIATE LABELS WITH INPUTS CONVEY ERROR STATE AND DESCRIPTION
- 21. 21VISUALLY HIDDEN CONTENT Choosing an Accessible UI Framework FOUNDATION: .hidden-for-[size] , .visible-for-[size] BOOTSTRAP: .sr-only JQM: .ui-hidden-accessible
- 22. 22VISUALLY HIDDEN CONTENT Choosing an Accessible UI Framework .u-hiddenVisually { border: 0; clip: rect(1px, 1px, 1px, 1px); height: 1px; overflow: hidden; padding: 0; position: absolute; width: 1px; }
- 23. TABS
- 24. 23TABS SOLUTION Choosing an Accessible UI Framework LEFT/ UP FOR PREVIOUS TAB ARROW KEYS SHOULD CYCLE TAB KEY FOCUSES ACTIVE TAB RIGHT/ DOWN FOR NEXT TAB
- 25. 23TABS SOLUTION Choosing an Accessible UI Framework Paypal Bootstrap Accessibility Plugin http://paypal.github.io/bootstrap-accessibility-plugin/
- 26. DIALOGS
- 27. 27DIALOG SOLUTION Choosing an Accessible UI Framework FOCUS SHOULD RETURN TO TRIGGER CYCLE FOCUS WITHIN DIALOG ROLE=“DIALOG”, ARIA-HIDDEN, ARIA-DESCRIBEDBY
- 29. CONCLUSION
- 30. 29CONCLUSION Choosing an Accessible UI Framework YOU NEED TO FILL IN THE GAPS CONTRIBUTE BACK NO SILVER BULLET SHARE YOUR KNOWLEDGE
- 31. CHOOSING AN ACCESSIBLE UI FRAMEWORK
Editor's Notes
- How many of you are are actively looking for a framework? How many of you didn’t make it to Karl Groves and Billy Gregory’s presentation? How many of you didn’t know Karl Groves and Billy Gregory were presenting at this same time? I will turn around and count to 10, if you want to leave I will not count it against you… For those of you here, thank you. You could have chosen to sleep in, or any other presentation, but I am glad you are here. INTRODUCTIONS
- Evaluating UI frameworks and libraries for your latest web development project is no easy task. Each decision maker has their own set of criteria based on their past experience and overall project or task at hand. Some common criteria factors are: ease of use, architecture, opinionated vs non-opinionated, customization, large community, open source, popularity, visual design, 3rd party modules, file size, MV* patterns, etc. Though determining this criteria is not covered in this discussion you need to ask yourself: Where does accessibility rank on your list of things to evaluate? Using one of these UI frameworks and libraries for your web project makes for rapid and easy development, so picking the right framework or library for your next web development project can have a serious impact on your ability to deliver on time and ensure future maintainability. Unfortunately, the speed and ease at which these frameworks allow you to develop often means that accessibility can easily be overlooked and taken for granted. NEXT SLIDE: How do you know the one you choose is accessible?
- How? We will go over some basic checks, a starting off point, on what to look for.
- It is not my intention to bash any of these frameworks. Building a framework is hard and takes a lot of work. I am extremely appreciative of these frameworks for the time and effort they have put in in order to make the development of my projects easier.
- Does the framework document a11y intentions? Do code examples exhibit a11y best practices?
- Proper labels/ descriptions: Is semantic meaning being conveyed? Keyboard navigation: Can a user perform tasks without the use of a mouse? Is focus indication defined, can a user know where they are at all times? Color Contrast: Is the CSS styles of each framework/ theme good for low-vision users? Minimum 4.5:1 If ARIA is needed, are the right roles, states, and properties being used? We will be using WAI-ARIA 1.0 Authoring Practices as our guide for widgets, i.e tab and dialog. Google Chrome Accessibility Developer Tools for inspection Google ChromeVox as screenreader
- Angular Doc: ngAria with code examples (aria-checked not updated?) Common a11y patterns Additional Resources Good info! Bootstrap Doc Foundation Doc Copied from Bootstrap? JQM Doc: Slim, mentions accessibly hiding menus
- Forms are everywhere! Extremely easy to get right, extremely easy to get wrong! Just good, semantic form markup! Error validation is usually customized, so some aria will be needed.
- Visit Angular FORMS Test keyboard and focus indication Test via chrome a11y tools, check label associations, check color contrast of validation ChromeVOX: CONTROL + COMMAND + A + A Check if error state is always read out loud Bootstrap forms Note about using labels for accessibility, Good documentation for a11y Forms are CSS only, meaning validation state should be handled manually via JS. No grouping, except for disabled groups of fields Foundation Forms "Note about labels and accessibility switches and range use custom elements, switches require strange, markup” Focus indication does not pass color contrast No grouping JQM Passed all except color contrast for default (blue/ white theme) Uses native form elements ensuring accessibility will always be supported even though highly stylized
- A “tabbed” interface that allows dynamic switching of content
- Tab to tabs Arrow keys? Focus indicaition Use a11y dev tools to check aria-roles
- Additional key combinations, CTRL + UP/ PAGE UP/DOWN are mentioned but might conflict with browser interactions, ie switching browser tabs. They are also somewhat Windows keyboard-centric
- List of tabs has a role=“tablist” Tabs have role=“tab”, property aria-controls with id of of content, and communicate selected state via aria-selected Content containers have role=“tabpanel” Visit Bootsrap tabs focus indication and color contrast is good Keyboard nav is not there Aria is ok Check with chromevox CONTROL + COMMAND + A + A Angular Tabs No focus indication on selected item Tab to control and left/ right arrows ok Not cyclical, no up/down. Navigation does not activate tab, must press enter Aria is ok JQM: PERFECT! Keyboard nav, color contrast, aria all perfect Foundation: No focus indication makes keyboard nav useless Tab to control and left/ right arrows ok Not cyclical, no up/down. Navigation does not activate tab, must press enter Aria is ok
- Overlay that either prompts user for a response or presents additional information
- Initial focus should go to either the first focusable element or the dialog container TAB/ SHIFT-TAB should cycle through focusable elements, never leaving the panel ESC should close the panel and return focus to the triggering element ENTER should submit form, if available but care is needed if other elements inside the dialog use ENTER.
- Role=dialog Simple dialogs like alerts/ confirmations should use role=“alertdialog” Dialog is labelled by either aria-label or aria-labelledby Additional aria seen later for better use Foundation Dialog Docs already note this is not accessible Tab not restricted to panel Focus does not return to trigger Esc and click outside does close dialog Invalid markup, no aria Check with Chromevox Angular Dialog Focus indication ok, keyboard , Tab not restricted to panel Focus does not return to trigger Esc and click outside does close dialog JQM: Good aria, tab not restriced to keyboard, focus not on trigger, esc and click outside to close Bootstrap: Tabs restricted, but there is shift-tab keyboard trap. Escape closes dialog
- So now we see that there are some things lacking in order to make the use of frameworks in our application more accessible. What are some of the things we can do?
- Again, forms are extremely easy to get right, and just as easy to get wrong.
- AFTER, show Angular FORM Code Add fieldset Explicitly associated labels with inputs Used fieldset with visually hidden css Color contrast of error messages changed Uses live-region to express error messages, but aria-descibedby might better in addition
- Just add js after after bootstrap Add ARIA roles like tablist, presentation, and tab for tabs UL, LI. Add tabIndex, aria-expanded, aria-selected, aria-controls for tab. Add ARIA roles of tabPanel, tabIndex, aria-hidden, and aria-labelledBy for tabPanel. Add keydown event listener for the tab to work with keyboard. Dynamically flip tabIndex, aria-selected, and aria-expanded for tab when it is activated and add aria-hidden to hide the previously visible tab.
- Wrap body content in container in order to maintain aria-hidden when panel is open Role=“dialog” Aria-describedby=“dialog-title” Aria-hidden Tabindex=0 Move close trigger to logical order, after title Change close trigger to button Close trigger being read as “multiplication”. Add aria-hidden and visually hidden text “close dialog” Focus close button upon opening Focus trigger upon closing Show code for tab cycle
- Angular – Marcy Sutton: undoubtedly biased, but Angular Material has some of the best accessibility support around for being a new framework. Angular 1.x had ngAria as a module, Angular 2.0 will essentially have ngAria built-in. Material Design won’t release components until a11y is built-in. Material Design enforces text alternatives via warnings in the console. Even better, a11y plugin for Protractor (e2e testing for Angular) that uses either Chrome Accessibility Developer Tools or Tenon.io by Karl Groves. Foundation – Brandon, Foundation Lead – Rafi, Customer Advocate: Next version of Foundation for web, v6, is being built from the ground up with a11y as a focus. No component will make build unless it passes a11y. Fixing docs, keyboard, and color contrast Bootstrap - Patrick Lauke V4 is a complete overhaul, with simplification and refactoring of most existing CSS/JS components Working hard trying to get Paypal a11y plugin back in Patrick will be overseeing/ triaging all new features/ pull requests Mostly volunteer basis
- This is it. We looked at some popular frameworks, some common interactions and patterns, used a basic checklist to evaluate and came up with some solutions. So what did we learn?
- Frameworks are hard to get completely accessible, implementations can vary. Ultimately, you need to do what is best for your users. Frameworks should give you the proper tools to do so. Share the knowledge, be an advocate. All the frameworks I tallked to said they greatly welcome any contributions/ pull requests to help with a11y. Open source is a community effort.