A framework here is anything that helps you to develop applications by providing you with a toolkit to build pages, components, interactions, visual styles. We are not going to be talking about CMS like Wordpress or Drupal here, however.
You may already be using a framework, or are considering starting or switching. In either case, you should examine the framework to see if it will allow, or even better encourage, or even best automagically produce accessible experiences that all of your users can take advantage of regardless of ability.
Below we list the questions you should ask yourself when choosing a framework regarding accessibility. In order to be able to answer them you must have access to a framework test bed that has all the representative components.
Note: taking a look at the framework in a test bed consisting of the un-configured starter app is only the first step in determining if it will provide an accessible experience. Frameworks will take different approaches: some will try to bake in accessibility by default, others will do very little but provide documentation for the developer to add accessibility configuration in. Others may not provide the developer the opportunity to configure components to make them accessible, or may allow it but provide no documentation on how to go about it.
Contact the web team with any questions or concerns.
Can you use the framework components without a mouse?
Some of your users will be using a keyboard to operate your application.
- Using only the tab key, can you navigate to all the controls in the display?
- Does the currently focused control show clearly that it has the focus?
- Is the sequence logical (top to bottom, left to right)?
If the framework is specific to developing mobile applications answering this question is a bit more complicated: can you use the framework app with VoiceOver?
Is there enough color contrast?
Some of your users will have a variety of low vision problems. Ensuring all the elements provided by the framework have enough contrast between background and foreground is important.
- Take a look at the representative view. Is there good contrast?
- Grayscale your monitor. Can you still see the elements clearly?
- Does your framework allow for theming? Can you change the palette if needed? If so you may address contrast issues this way.
Do web components or custom elements behave with the keyboard the same way their native correlates?
See MDN for a definition of web components.
Some of your users will be using a keyboard to operate your application. If your framework is providing you widgets, controls, etc., these things also need to be operable with the keyboard.
Perhaps an example may help. A modal is not a native web element, the concept comes from the realm of desktop applications. In order to provide it in the web context, frameworks construct modals with primitive web elements (usually a mass of divs) and Javascript functions. Does the framework-provided modal behave in the same way the desktop modal does?
- Is the keyboard focus sent to modal when invoked?
- Is the keyboard focus trapped in the modal?
- Is the masked content unavailable to the keyboard?
- Does the ESC key dismiss the modal?
- When modal is dismissed, is the focus returned to the control that invoked it?
Same for other elements. A pull down menu, for example, is constructed by frameworks usually as a trigger (button or link) and a list (of lists sometimes). Does it behave the same way as a native desktop menu?
- Can you tab to the trigger?
- Can you navigate the revealed list with the arrow keys?
- Is the menu dismissed with ESC or when it loses focus (when you tab out of it)
Other web components may be:
- Navigation drawer
- Hamburger menus
- Collapse
- Dropdowns
- Trees
- Modals
- Navs
- Navbar
- Pagination
- Popovers
- Autocompletes
- Progress indicators
- Sliders
- Selection controls (checkboxes, radios, switches)
- Snackbars (toasts, other growl-like notifications)
- Tabs and tab panels
- Tooltips
- Pickers (date, time, color,etc)
Do web components interact well with the accessibility tree?
Do they provide the right information to the accessibility tree about their names, their roles and their states? This one is going to be hard to test, might want to just take a look at a few simple web components.
For example: take a look at how a menu web component in chrome://settings/addresses was inspected. Using Chrome developer tools, view the Accessibility panel.
The component is <cr-icon-button>, but because it has the right role and name, the accessibility tree panel reports it as button "More actions". If one of the menu items where to be disabled, the status of disabled would also be reported in the tree.
This is complex stuff. You may consult the documentation of the framework to answer this.
Does the framework allow you to extend the web components?
You will inevitably run into situations where a given component does not provide the right information to the accessibility tree. Does the framework allow you to add attributes and values to the component?
For example - imagine the framework gives you an excellent modal that behaves exactly like a good modal should (see list above). But the accessibility tree reports nothing. Does the framework allow you to add role=”dialog” and aria-labeledby=”id of label element” to the modal wrapper, as well as an element that will contain the modal name?
Does the framework track and address accessibility issues?
This is easy to check with open source frameworks and another reason to go open source. Go to their GitHub or GitLab page and check it out. If accessibility issues are being filed and addressed in a decent amount of time, that is a good sign. If not, this is not a deal breaker: if in all other respects the framework you are considering is excellent, consider contributing to it to address accessibility issues.
Does the framework have accessibility documentation?
First: does the framework publish an accessibility statement? Does the statement mention compliance with guidelines (like WCAG 2.0 or 2.1)?
Second: most frameworks that consider accessibility will emphasize that it is up to the developer to use the framework correctly by following the documentation. Is this documentation regarding accessibility configuration options clear and detailed? Good examples are Bootstrap and Material Design.