For Product Owners: Accessibility Testing & Requirements

Owned by Khalilah Gambrell
Last updated: Jul 12, 2021 by egerman
6 min read

Table of Contents

Why is accessibility important? 

“Accessibility is the right thing to do. And not just the right thing; it’s profoundly the right thing to do, because the one argument for accessibility that doesn’t get made nearly often enough is how extraordinarily better it makes some people’s lives. How many opportunities do we have to dramatically improve people’s lives just by doing our job a little better?” 

Steve Krug (author) "Don’t Make Me Think: A Common Sense Approach to Web Usability"

The FOLIO platform must be WCAG 2.1 AA compliant and this requirement is also included in the Technical Council's Definition of Done draft.  WCAG 2.1 AA compliance is important as many libraries have accessibility requirements by law or by policy and require software providers to complete a Voluntary Product Accessibility Template (VPAT) to describe its accessibility efforts. Accessibility is a key factor whether an institution will use a product/platform.

An accessible platform is a combination of a.) complying with web development best practices and b.) standard user interface (UI) patterns, and c.) clear/concise messaging. No one accessibility compliance tool/service can capture all accessibility issues. A combination of accessibility compliance tools and user testing is required to validate a platform's accessibility. 

POs must play a role in ensuring that web development best practices are followed and that some level of user testing is conducted. The effort is not time-consuming AND should be included in frontend developers and POs' definition of done.  And this effort will improve the user experience of all FOLIO platform users.  

TEST! TEST! TEST! 

Keyboard testing must be conducted on all apps.

Keyboard testing is one of the best and easiest ways to identify accessibility issues. If a user must use a mouse to navigate or complete an action then it is not accessible.  Keyboard testing should take no more than 30 minutes for the most complex of apps. Check out a great table by WebAIM on how to conduct keyboard testing https://webaim.org/techniques/keyboard/#testing. 


Keyboard focus is on Titles tab

When conducting keyboard testing you want to check: 

  • Navigate a page in a logical order. Are you able to use the keyboard to navigate on links/actions/content in a way that makes sense? A logical order is one where you navigate a pane/page left to right and from top to bottom.  
  • Ensure focus is clearly indicated. As you navigate FOLIO with a keyboard, it is important that the focus is clearly indicated as shown on screenshot.

How to start this effort? 

  • Add to your team's definition of done for frontend developers to conduct keyboard testing on applicable user stories. This test should not take very long! 

  • POs should schedule time (at the end of a quarter) to conduct keyboard testing of his/her apps. Add these stories to your backlog with the label 'a11y.' If you are unable to do so, then ask a SIG member to assist. 

  • Remind your team that WCAG 2.1 AA compliance is a condition of definition of done. Please have them reach out to John Coburnfor more developer details.



Color contrast analysis tool must be run on all apps 

Poor contrast makes for a poor user experience for all users. FOLIO must be in compliance with WCAG 2.1 Priority AA Color Contrast requirements which are the following: "The visual presentation of text and images of text has a contrast ratio of at least 4.5:1." Read more at https://www.w3.org/WAI/WCAG21/quickref/#contrast-minimum. 

Running Inventory app through a color contrast tool. 

The screenshot reflect running a color contrast analysis tool on the Inventory app. Note that the app passes with the exception of the publisher and publisher year values on the pane header. In addition to running this tool, ask yourself, do you find the FOLIO UI easy to read? If the answer is NO then color contrast maybe one of the culprits. 

How to start this effort?

  • Add to the definition of done for UI designers/frontend developers to verify color contrast meets WCAG 2.1 Priority AA color contrast requirements with this Chrome plug-in: https://chrome.google.com/webstore/detail/wcag-contrast-checker/plnahcmalebffmaghcpcmpaciebdhgdf.
  • Have this tool run at least once a quarter. Issues should be added to the backlog with the label 'a11y'. Updates can be made by Rasmus or your app's frontend developers. NOTE: POs may need to add a user story for UI designer/frontend developer to run this tool.

Accessibility compliance checker tool must be run on all apps

Accessibility Compliance Checker(s) will not capture all accessibility issues. But many will capture the following issues: missing alt tags, missing labels, missing headings, missing IDs, etc (all things markup). A free Chrome extension to use is the aXe Deque compliance tool, for more details, visit https://ux.folio.org/docs/assets/axe/. Run the checker and quickly get results.  NOTE: This tool may return false positives for color contrast issues. This is due to FOLIO's use of colors that accessibility compliance checker tools do not have support to check. So ignore color contrast results for now. 

Accessibility Compliance Checker - Inventory App results

How to start this effort?

  • Add to the definition of done for frontend developers to run app through an Accessibility compliance checker once a quarter. All issues should be added to the backlog with the label 'a11y'
  • In addition to the aXe Deque compliance tool, developers can use a nifty Web developer plug-in  https://chrispederick.com/work/web-developer/.

User testing is important 

"Queensland Urban Utilities" by Luciana Albuquerque is licensed under CC BY-NC-ND 4.0 

Using the tools and practices described above will identify many accessibility issues but user testing will remain the method for validating the user experience!

How to start this effort?

  • Ask a SIG member if s/he is willing to test an app/feature using a screenreader OR a keyboard. 
  • Contribute to a monthly Usability Power Hour conducted by the Accessibility SIG. If you have a feature that you want tested by an accessibility SME, please contact egerman or Khalilah Gambrellfor details.


POs | What your requirements should consider

Readability. Keep language simple, consistent, and accessible

POs can support accessibility by ensuring that the language used on the FOLIO platform is simple, consistent, and accessible. Yale has a great document on ensuring language supports accessibility https://yale.app.box.com/s/pfxe0q6gnx07pbq6qjl7dd12taqzd21z. And also review WCAG documentation: https://www.w3.org/WAI/tips/writing/. 

Tips

  • The UI should have clearly defined headings and labels. 
  • Language should be jargon free.
  • Language should provide context. Bad example: 1. click here means nothing to a person using a screenreader.
  • Always choose brevity. Redundancy and extensive alt-text reduces ease of use for those who use screenreaders.

Color and images/icons

Color can never be the only UI indicator.  Same for images. In the case of images/icons, if you have a label then you are good. If you do not have a label then include in your user story an alt text requirement for that image/icon IF that icon is meaningful. Alt text allows the screenreader to read the image/icon's description. For more details on when to apply alt text, please read this WebAIM post https://webaim.org/techniques/alttext/. 

Good example | alt text is not required because a label displays

Bad Example | Color can never be the only UI indicator on Settings > System Information


Tips

  • Never have color as the only UI indicator of content/action/etc. 

  • If an image/icon does not have a label then include in your user story an alt text requirement for that image/icon. 

  • Don't make alt text that is redundant (aka already included on the page as text). The screen reader will read both the page text and the alt text, which can be confusing for the user.

Forms Accessibility 

eholdings: New custom title form

Tips

  • Each form field must have a label 
  • Clearly indicate if field is required
  • Clearly indicate error messaging tied to form field visually and via screenreader

Put yourself in the position of a screenreader user when defining UI designs and requirements. 

For example, no update or action should automatically occur without a screenreader announcing a change. A screenreader user must be made aware of what is happening on the user interface. 

Uh-oh: Inventory App currently displays results by default

Tips