Tag: Checklist

How to Improve Screen Reader UX

a11y-sailorLeave a comment
Reading Time: 4 minutes
A human ear coming through a hole on a sheet of paper.
An ear coming out through a hole on a white sheet of paper (listening to component interaction is key to improving Screen Reader UX).

This is a non-comprehensive list of recommendations on how to improve the Screen Reader User Experience (UX). This list has worked for me in the past to get consistent results between planning and deployment. This article is mostly addressed to developers, visual and interaction designers, and QA testers. Not all recommendations apply to every role, but all outcomes are helpful for everyone. Other project stakeholders, like Project Managers, can benefit from knowing these recommendations. This is not a formal checklist but it can be the foundation for one.

There is a layer under every User Interface (UI) that “speaks” to the users. And I mean literally speaks to them. If it doesn’t, then something is wrong with the UI. Most of the time, individuals unfamiliar with Web Accessibility don’t realize this.

Same as we usually test by visually browsing and testing with the mouse. Performing tests with keyboard-only navigation and Screen Readers are becoming a requirement. To hear what components and their interaction sound like. Needless to say: silence is bad.

There is no replacement for hands-on manual in-person Screen Reader testing. To the writing of this article, there isn’t any automatic test for Screen Readers. Testing the Screen Reader UX from conception to implementation is one way to improve it.

General Improvements to Screen Reader UX

  1. Define user journeys for every UI or page. Write it down as a numbered list. E.g., “User Tabs to component A, then uses the down-arrow key to reach element A1, …”.
  2. Video record screen reader sessions based on defined user journeys. Make sure to enable “computer audio recording”, otherwise it will result in a video without audio. Video recordings are a great reference when explaining to a developer how to reproduce screen reader bugs.
  3. Test in as many different screen readers as possible. Some are free, some are pricy, some are strict, and some are very forgiving.
  4. Test accessible gestures for mobile devices, but also small devices with external keyboards. E.g., Android Tablets with external mini keyboards.
  5. Beware of cross-screen-reader bugs and aim towards cross-screen-reader solutions. E.g., VoiceOver for Mac will vocalize just about everything, including dynamic content. As opposed to JAWS/NVDA for Windows, which may need a preloaded parent tag for similar results. That is to say, vocalization varies from one Screen Reader to the next, depending on implementation, platform, and devices.
  6. Be patient while testing ARIA attributes. Testing vocalization will take much longer (even at expert levels) than the usual “Mouse + Browser” testing. This is normal, adjust expectations and time estimates.
  7. Make sure to test for consistency and double-check screen reader vocalization across different environments. E.g., localhost, development, staging, live.
  8. Video record experimental approaches to improve Screen Reader UX that didn’t make it to the final implementation. Save for future recycling.
  9. Video record the approved “final” outcome to avoid and spot regressions.

Improving Screen Reader UX by Role

  1. As a Designer, explore examples and references using a screen reader (desktop and mobile). Listen to what components and elements sound like. Video record the screen reader exploration sessions to show to developers and other stakeholders. Point out cross-screen-reader vocalization differences as soon as spotted; they tend to be forgotten.
  2. As a Developer, test with a Screen Reader while developing. If designers provided a video recorded session of the expectations, try to aim for a similar result (desktop and mobile).
  3. As a QA tester, add video recordings of screen reader bug detections to QA tickets (desktop and mobile). This will help developers reproduce and debug issues faster than reading text and interpreting the instructions on how to reproduce. It saves on explanations about how to reproduce and issue.
  4. As a stakeholder, be aware of cross-screen-reader differences and limitations.

What to Avoid

  1. Avoid using Chrome extension to replace or emulate Screen Readers software. The only focus of emulation should be to emulate the user, not the software. As of the writing of this article, I haven’t come across an extension that emulates some ARIA scenarios. Such as aria-expanded, or aria-live which already have some cross-screen-reader issues when using real software, so avoid emulators.
  2. Avoid turning off the screen reader when it starts vocalizing. Instead, listen to it speaking, and try to associate the speech with the UI component and the interaction. I have to admit this happened to me at the beginning. Then I realized THIS is exactly what I should be testing: vocalization. Last year I wrote an article about overcoming the uneasiness of screen reader testing. It’s a helpful guide for slowly adapting to that new environment.
  3. Avoid browsing the UI with the mouse while using a screen reader. This prevents hearing some additional instructions the Screen Reader might be vocalizing by default. E.g., specific keyboard key combination to interact with the component. Don’t skip components or elements with the mouse, always use keyboard-only navigation.
  4. Avoid including ARIA attributes without actually testing them with a Screen Reader and listening to how they sound.
  5. Avoid listening to music while testing with screen readers. Some developers and designers like to hear music or watch videos while working. Honestly, so do I, but then suddenly hearing the computer speaking might be distracting. This could make a slow process even slower.

In short

  1. Listen.

The Accessibility Advocate Checklist

a11y-sailorLeave a comment
Reading Time: < 1 minute
The hand of an Accessibility Advocate checking boxes on a checklist

This Accessibility Advocate Checklist is a compass. A non-thorough and non-technical Accessibility checklist for the person taking the role of Accessibility Advocate in a development team. All steps in this checklist lead to knowledge discovery for the Advocate as well as for team members.

Identify

  • Critical user journeys.
  • Testing cases and QA scenarios for Accessibility

Verify

  • All User Interface components have Keyboard Accessible Patterns.
  • User journeys are doable using only the keyboard.
  • Keyboard traps do not interrupt or prevent user journeys from being successful.
  • User journeys vocalize properly using a Screen Reader with keyboard navigation.
  • If the project is for government employees in a regulated environment.
  • VPAT document preparedness if required.
  • If we need the services of an Accessibility Test Center for this project.

Ensure

  • Stakeholders are aware of the consequences of not complying with Accessibility requirements for this project.
  • The team is aware of the WCAG 2.1 level of compliance for this project.
  • Developers know where to find the Success Criteria and Techniques for WCAG 2.1.
  • Team members have a link to a predefined Accessibility Resource Center according to their roles.
  • There is a documented plan for gradually implementing Accessibility (a Roadmap).

Web Accessibility Questions for Job Interviews

a11y-sailorLeave a comment
Reading Time: 3 minutes
one man and two women seated at office table during job interview for a web accessibility position
The image shows two women conducting a job interview with a male candidate in an office with a city view.

As I wrote in a previous article, Web Accessibility Jobs are on the rise. This inevitably points to a job interview. It would be of great help if people involved in the recruitment process added some Web Accessibility questions to the interview. Especially for non-expert positions. That way, word will spread that this is something the hiring company values in candidates.

In my experience candidates will at least read about it later if they miss answering during the interview. Depending on the position, sometimes the hiring happens, sometimes it doesn’t, but the “Accessibility Seed” will be planted in that person’s mind. Using that “seed” analogy, let’s apply that to the questions.

5 Seed Questions for Interviews

Now, what are good questions to ask in order to assess the candidate’s knowledge about Web Accessibility? Short and sweet, if we are NOT hiring an “Accessibility Expert”. In my experience, these open-ended questions will have answers like “no”, or detailed descriptions. Also, they will leave candidates thinking, even if they don’t know the answer:

  1. Do you know what Skip Links are? … if yes, elaborate.
  2. Do you know what a Screen Reader is? … if yes, elaborate.
  3. Do you know what the Accessibility Tree is? … if yes, elaborate.
  4. Are you familiar with ARIA? … if yes, elaborate.
  5. Are you familiar with WCAG? … if yes, elaborate.

Explanation: If candidates don’t know what Skip Links are, they are most likely not familiar with Keyboard Navigation, which in turn is a must for Screen Readers, which happens to vocalize the Accessibility Tree, there where we use ARIA to fix issues related to it. Mentioning WCAG just makes sure the candidate has never heard of Web Accessibility before. That, if the four previous were negative answers.

All 5 are easy to remember by candidates: Skip Links, Screen Reader, Accessibility Tree, ARIA, WCAG. All 5 are great entry points for research and personal improvement. They all dive deeper into knowledge areas shared by Designers, Developers, Product Owners, Managers and Testers. Even without them knowing.

It really depends on the position we’re hiring for. Questions will not be the same when hiring for a Web Accessibility Engineer/Specialist, or when hiring for a Frontend Developer, a Tester or an Intern.

Interview Questions for Experts

A quick search on Google for “web accessibility interview questions” will result in some of the links listed at the end, which are very good and detailed, but in my opinion, not all the questions apply to just any candidate. They all seem to be addressed to hiring either Web Accessibility Testers or Web Accessibility Engineers or Specialists.

Yes, it would be great if all candidates knew all those answers. But honestly, unless we are hiring experts most people don’t know, and they are not to blame. Web Accessibility is not new. Browsers, software, and laws that support it have been around for decades. What is new, is that the number of lawsuits became alarming around 2017 in the US. These days, it is a must-have for websites in North America with other regions following along. So, realistically, this is still new for way too many people.

Now, for non-expert positions. Candidates failing to answer any of the previous 5 seed questions should NOT prevent the hiring of candidates if they shine in other areas. Web Accessibility can be learned without having to know the theory. Also, there’s no better way to start understanding it than to power up a Screen Reader, start browsing and stop for silent elements.

Nonetheless, this is interesting and precious information to have handy. So, I’ll leave them here and come back to this list as I find more resources on the Job Interview topic: