Accessibility review of the We Are Blood online questionnaire

I’m a regular blood donor with our local blood bank, We Are Blood. If you’ve ever donated blood, you know that part of the process is answering a bunch of health-related questions first to help determine your eligibility. Being sick, taking certain medications or having had certain illnesses can exclude you from donating.

I’m donating blood this Friday and was thrilled when today’s reminder email announced a new option to complete the pre-donation questionnaire online, before coming in for my appointment. I decided to check this process for web accessibility. Let’s begin!

Welcome to QuickPass page

The email links to the Welcome to QuickPass! page which has a lot of accessibility issues, and this is just the instructions. I ran both the Lighthouse and Axe accessibility audits in Chrome and the results were not good.

  • Lighthouse score: 47/100
  • Axe automated issues found: 28
Screenshot of the top of the Welcome to QuickPass page

Some site-wide issues

  • The entire We Are Blood website is missing a “skip to content” link that would allow users to bypass the repetitive navigation links.
  • The “We Are Blood” logo is embedded SVG code that does not provide any text alternative and is announced by the NVDA screen reader as “weareblood.org link.” The logo should include a <title> element with the text “We Are Blood. Drawn together since 1951.” Doing this will enable a screen reader to communicate the logo to users with visual impairments who cannot see it.
  • The five links in the site’s main navigation all have dropdown menus that are accessible on mouse hover only. To be accessible, users must be able to use all website components with a keyboard.
screenshot of the dropdown menus on the We Are Blood website.
  • The newsletter signup form in the footer uses positive tabindex values. The result? When a keyboard user tabs from the browser address bar into the page, the first focusable element is the “Full Name” field in the form, which is confusing because it violates the natural reading order of the content. The second focusable element is the “Email Address” field. The third focusable element, though, is not the form submit button—it’s the “We Are Blood” logo link because after the positive tabindex values, the tabindex goes to the beginning of the content.
  • The newsletter signup form submit button is missing a text label. The screen reader announces “Contentinfo landmark button.”
  • The newsletter signup form fields use placeholder text instead of <label> elements.
screenshot of the newsletter signup form showing the two fields have positive tabindex values.

There are several color contrast issues where the contrast ratio between the text color and background color fails to meet the 4.5:1 requirement for regular, unbold text. For example, the gray text in the screenshot below from the footer has a contrast ratio of just 3.13 on a light blue background.

screenshot showing poor color contrast of gray text on a light blue background.

Content issues

Arguably, the most important thing on this page is the link to start the questionnaire. While visually it looks like there is a big button that reads “Click here for QuickPass,” a screen reader announces “welcome cust=WRB link” because no alternative text is provided on the image. The alt attribute must contain the same text that is in the image.

click here for QuickPass button.
<img class="aligncenter wp-image-2040 size-full" src="http://weareblood.org/wp-content/uploads/2018/05/QuickPass-Click.jpg" alt="" srcset="https://weareblood.org/wp-content/uploads/2018/05/QuickPass-Click.jpg 600w, https://weareblood.org/wp-content/uploads/2018/05/QuickPass-Click-150x57.jpg 150w, https://weareblood.org/wp-content/uploads/2018/05/QuickPass-Click-300x113.jpg 300w" sizes="(max-width: 600px) 85vw, 600px" width="600" height="226">

The page content skips heading levels. It starts correctly with <h1> for the “Welcome to QuickPass!” main heading, but then skips to <h4> for the heading “A couple of key points”, then to <h3> for headings in the footer.

QuickPass questionnaire pages

The questionnaire begins on the ABO QuickPass page.

  • Lighthouse score: 43/100
  • Axe automated issues found: 6

This start page does not support keyboard or screen reader usage because the entire thing is marked up as a form. Screen readers enter a different mode when they encounter a form, which disables the navigation hot keys, in order to allow users to type in form fields.

screenshot of the questionnaire start page with overview text and a large button that reads start questionnaire.

Here is how the body copy is marked up inside the <form> element:

<h1 style="text-align:center">
<font color="#E36B50">Hey Blood Donor!</font><br><br>
<font color="#01426a">Thank you in advance for taking the time to fill out this questionnaire.<br><br>Please ensure you are answering all questions in a private, confidential setting and that you read each question in its entirety before answering. Skip the question if you do not understand or have questions of your own.<br><br>Please note that your questionnaire answers are good for today only and that additional questions will need to be answered at the donation site.</font></h1>

Donor information page

Since this page actually contains form fields, it works better with the keyboard and screen reader, but it still has serious HTML markup issues.

  • Lighthouse score: 55/100
  • Axe automated issues found: 5
screenshot of the donor information request form with fields for name, gender and birth date.

Here’s the markup for the “First Name” field:

<span class="formleadinglabel">First Name:<span class="required-indicator desktop">*</span></span>
<span class="formfield">
<input type="text" id="firstname" name="firstname" maxlength="15" class="required" value="" autofocus="" autocomplete="given-name" placeholder="First Name">
<span class="required-indicator in-field mobile">*</span></span>
  • The form field labels are not <label> elements and, therefore, are not associated programatically with their <input> elements.
  • None of the text input fields are announced as required.
  • The day, month and year combo boxes are not announced as being for “Birth date” so screen reader users have no idea what date they’re being asked to enter.

Even if keyboard users are able to complete the form fields, they cannot continue to the next screen because the “Continue” control isn’t marked up as a button, preventing it from gaining keyboard focus. It’s also a background image without any text alternative.

<div id="btnContinue"></div>

Question pages

I didn’t complete the entire questionnaire today but the question screen has repeatable patterns and problems.

screenshot of the individual questions within the QuickPass app which have a question and three radio buttons for yes, no or skip.
  • The volume controls do not have text labels, which is really ironic if you think about someone trying to use this with a screen reader.
  • Keyboard users cannot tab to the radio buttons or select an answer.
  • There are two <label> elements per radio button <input> and the one with a text label has a CSS class which hides it. 🤦 The screen reader announced “clickable, clickable, clickable.” Here’s the markup:
<input id="yes" class="answers" type="radio" name="answer" value="Y">
<label class="default-label" for="yes"></label>
<label for="yes" class="hidden">yes</label>

I am happy to have the option to complete these questions before I head to the blood bank, but it’s not accessible for many people with disabilities. I hope We Are Blood requests that the vendor make its software comply with the Web Content Accessibility Guidelines so that everyone can use it.

How to give your Yammer image uploads alternative text descriptions

At work, we use Microsoft’s social media tool Yammer. It wasn’t clear to me how to give alt text to uploaded images, so I searched through the Yammer support documentation and found a page on accessibility in Yammer. But neither that page nor a supplemental page on using a screen reader with Yammer mentions alt text or images.

screenshot of my Yammer feed with an uploaded image

Looking at the HTML code in my feed, I saw that images are marked up as background images on <figure> elements and contain default descriptions as <figcaption> elements.

<figure style="background-image: url('https://www.yammer.com/image-file-path/preview');">
<figcaption>
Attached image: No description set. Image-File-Name.jpg Click to open full-page preview.
</figcaption>
</figure>

When you click on an image in your feed, it opens in a modal overlay and displays the image as an <img> element which does have an alt attribute with similar default text.

<img src="image-file-path" alt="Uploaded image: No description set. IMAGE-FILE-NAME.jpg">

In both instances, the default text shows No description set.

Usually, alternative text would not include the image file name. I think Yammer does this because it is also a file sharing tool and in that context, knowing the file name could be useful.

Add a description when attaching an image to a post

Like Twitter and Facebook, Yammer offers the ability to provide an image description when attaching a file to a new post. This option is so hidden, though, that I never noticed it and assumed for a long time it wasn’t possible! I messaged the Microsoft Accessibility team to ask when Yammer would support alt text for user-posted images and got this response:

Thanks for reaching out. When you upload an image to post in Yammer, there is some helptext below the image prompting you to add a description. Please let us know if that’s not what you’re looking for.

@MSFTEnable on Twitter

Sure enough, after the image uploads, there is a tiny line of text beneath the file name that you can click on to enter an image description. It reads:

File attached. Before you post, add a description to this file so it’s accessible to everyone.

screenshot of an image attachment on a Yammer post with the input field to add an image description highlighted

Tip: End your description with a period so that screen readers pause before announcing the file name.

Add a description to any previously uploaded image

  1. If you’ve already uploaded your image, click it to see the full-page preview screen
  2. At the bottom right of the screen, click the Go to File link
  3. On the file details page, there is an input field that reads “This file doesn’t have a description yet, click here to add one”.

    Click the input field, enter your image description, then click outside of the field to save it.
screenshot of the Yammer image details page with a highlight around the input field to add an image description

From my testing, I’m able to add and edit descriptions for images uploaded by other users too, even if I don’t follow them or belong to the group where the file is posted.

Web accessibility for content authors

This week, I gave a presentation about web accessibility to the content authors of our corporate marketing website who combine text, images, video, etc. into web pages using a content management system (CMS). I’ve found it challenging to tailor web accessibility information for different audiences (developers versus content authors) including how to break it into manageable chunks that go just deep enough during an hour-long meeting to keep folks engaged while encouraging them to learn more on their own.

I began by asking for their help. Our content authors are the people interacting with the website most frequently and they are in a prime position to uncover and report issues, including limitations of the CMS. As they learn and practice web accessibility, my hope is that we are able to use their questions and concerns to grow a culture of accessibility in the company.

What is web accessibility?

Definitions of web accessibility often frame it as a way of making the Web work for people with disabilities but that framing has started to seem problematic because it focuses on disability instead of acknowledging that all of us experiences the Web with a range of preferences and abilities.

Web accessibility is creating websites and web applications that are inclusive of as many people as possible.

No matter what digital space we’re designing for, we must make the choice to be inclusive by having a clear awareness of the diversity of our users and their interaction preferences.

Web accessibility benefits everyone

While improving information access for people with permanent disabilities like low vision, hearing loss and fine motor control tends to be the main focus of web accessibility, accessible design creates a better experience for all of us by also supporting

  • Changing abilities due to ageing, like needing larger text size. Every day, I find myself using CTRL++ to make web pages easier to read.
  • Temporary disabilities such as a broken arm or lost glasses. Any of us at any time can experience a change in ability.
  • Situational limitations like using a screen in bright sunlight or watching video with the sound muted. I use video captions all the time, though I don’t have a hearing impairment.
  • Limited bandwidth or a slow Internet connection. Millions of people, even around major metropolitan areas in the US, don’t have high speed internet access (2019, Pew Research Center Internet/Broadband Fact Sheet).

Accessibility is a civil right

People are excluded from every aspect of society when we don’t design and build in accessible ways. We infringe on the privacy and security of our users if they must depend on help from others to interact with our websites and web applications. Many law-making bodies are writing and passing legislation to help address the problem of public accommodation and equal access:

We have a responsibility to provide our users with accessible information and it’s very doable when we think about accessibility as design methodology.

Disability is never a barrier.

Design is.

Haben Girma, first deafblind graduate of Harvard Law School

Web Content Accessibility Guidelines

I work for a Canadian company that must comply with the AODA which references the Web Content Accessibility Guidelines (WCAG). WCAG is a set of best practices for improving information access that has been around since 1999. The 13 guidelines are categorized by four principles:

WCAG: Perceivable, operable, understandable and robust.

Perceivable

Information and user interface components must be presentable to users in ways they can perceive.

  • Guideline 1.1 – Text Alternatives: Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language.
  • Guideline 1.2 – Time-based Media: Provide alternatives for time-based media.
  • Guideline 1.3 – Adaptable: Create content that can be presented in different ways (for example simpler layout) without losing information or structure.
  • Guideline 1.4 – Distinguishable: Make it easier for users to see and hear content including separating foreground from background.

Operable

User interface components and navigation must be operable.

  • Guideline 2.1 – Keyboard Accessible: Make all functionality available from a keyboard.
  • Guideline 2.2 – Enough Time: Provide users enough time to read and use content.
  • Guideline 2.3 – Seizures and Physical Reactions: Do not design content in a way that is known to cause seizures or physical reactions.
  • Guideline 2.4 – Navigable: Provide ways to help users navigate, find content, and determine where they are.
  • Guideline 2.5 – Input Modalities: Make it easier for users to operate functionality through various inputs beyond keyboard.

Understandable

Information and the operation of the user interface must be understandable.

  • Guideline 3.1 – Readable: Make text content readable and understandable.
  • Guideline 3.2 – Predictable: Make Web pages appear and operate in predictable ways.
  • Guideline 3.3 – Input Assistance: Help users avoid and correct mistakes.

Robust

Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.

  • Guideline 4.1 – Compatible: Maximize compatibility with current and future user agents, including assistive technologies.

Creating accessible content

The accessibility focus for our content authors using a CMS to build web pages is different than the focus of the front-end developers creating the templates, themes and widgets that comprise the basics of a website. Just as I am typing this post into a text editor in WordPress, rarely touching any HTML, our content authors aren’t usually coding; they are marking up text and inserting media through a GUI.

Their concern is evaluating individual web pages, not the website on the whole. They need to be able to identify and remediate issues in their content that differs from site-wide issues with repeated elements in the header and footer or problems introduced by CSS.

Checklists

The AODA specifically requires WCAG version 2.0, level AA conformance for a total of 36 success criteria. When I was first learning about these, I found it really overwhelming. I still find the WCAG format intimidating because there is just so much information to reference. Thankfully, many people and organizations have created checklists that present the success criteria in simpler ways.

  • Easy Checks: A first review of web accessibility that breaks out the basics for beginners. I used this streamlined list when I did the first accessibility audit of our corporate marketing website.
  • The A11y project checklist: Uses plain language suggestions of what to review by content type like images, forms, headings and tables.
  • WebAIM checklist: A comprehensive checklist organized by success criteria and supplemented with clear examples. WCAG 2.1 updates are included and highlighted.

Accessibility testing

Testing is imperative so it’s important to find tools that work for you. The choices are vast and most tools run similar checks against the same WCAG success criteria. For content authors, I suggest trying WAVE (the Web Accessibility Evaluation Tool) which can be added to Chrome and Firefox as a browser extension. It provides a simple, graphical overlay showing automated testing errors in context. Additionally, it exposes hidden data like heading order and alt text that aids in manual testing.

screenshot of the WAVE tool

Passing an automated test doesn’t mean a page is accessible. For example, automated tools can detect that an <img> element has an alt attribute, but they can’t decide if it’s good alt text.

Automated accessibility testing tools can catch only about 30% of possible errors.

Manual testing tips

Get started with web accessibility

Check out the W3C’s Web Accessibility Initiative website with strategies, standards and supporting resources to help you make the Web more accessible. The “Accessibility Fundamentals” section includes:

The power of the Web is in its universality.
Access by everyone regardless of disability is an essential aspect.

Tim Berners-Lee, W3C Director and inventor of the World Wide Web