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.


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.


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.


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.


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.


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

YNAB addresses color accessibility

In a recent product update YNAB (You Need a Budget) announced it had made some change to the way it uses color to convey meaning about budget amounts. When I logged into the online webapp today, I saw this modal message dialog. (The content of the announcement is below the image.)

screen shot of a modal announcement dialog in the YNAB web application

Sarah from YNAB

Hi there,

As you probably know by now, we really care about your experience in YNAB. Like…really really care. We are always looking for ways to make things easier, more user-friendly, and just prettier.

We’ve heard that the colors in your category Available balances (or “pills” as we like to call them) make things a bit difficult to read. When we hear feedback like this, we gotta do something about it. We want YNAB to be accessible to everyone, so we’d like to introduce our new pill colors:

screen shot showing the before and after colors used by YNAB to show budget category information. the before colors are orange, green and red with white text. the after colors are lighter shades of the same colors but with text now a darker shade of each, which has better contrast.

In case you’re wondering, green still means green. Yellow still means yellow. Red still means – you guessed it – red! The only thing that’s changing is the increased contrast, which makes things a bit easier on the eyes.

The message links off to a blog post that discusses the changes further: A Budget That’s Easy On The Eyes

YNAB took note of two accessibility issues

  1. Previously, it used color only to convey the meaning of a budget amount which does not meet success criteria 1.4.1 (level A) Use of Color.

    “We added visual signals to the Available amounts to make it clear whether there was credit overspending or an underfunded goal. We also increased the size of the negative sign for overspent categories. Both of these changes help users with visual impairments easily scan their budget by relying less on a color-based signal.”

  2. The color combinations of white text on an orange background (2.54) and white text on a green background (3.31) failed the color contrast requirement of 4.5:1 for success criteria 1.4.3 (level AA) Contrast (minimum).

    “We significantly increased the contrast between the color of the background (the ‘pill’) and the text, while muting the background color. These changes increase the contrast in general, which makes the text easier to read for everyone.”

The new color combinations do indeed satisfy color contrast requirements now.

YNAB budget colors
Amount typeFG colorBG colorContrast ratio
Negative #651c0b#f7c1b57.68

This is a screen shot of how the colors actually look when viewed in the YNAB application. Note that I don’t see a check mark icon next to the positive amount:

screen shot from the YNAB app.

YNAB acknowledges that it is still problematic for users who experience deuteranopia:

While this helps with readability, we still use red and green to send signals about Available amounts, which isn’t the ideal experience for anyone with red-green color blindness.

Below is an example of what these colors might look like for these users. It’s actually the difference between the red and orange pills that is nearly imperceptible.

screen shot of the YNAB colors using a filter that simulates red-green color blindness.

It’s great to see more web applications incorporating accessibility. Now if only it were clear what those three icons at the bottom of the modal message window mean. They have aria-label attributes on some emojis that are not at all informative:

<span class="intercom-reaction" aria-label="green heart reaction" aria-pressed="false" role="button" tabindex="0"><span>💚</span></span>

<span class="intercom-reaction intercom-reaction-selected" aria-label="sleeping reaction" aria-pressed="true" role="button" tabindex="0"><span>😴</span></span>

<span class="intercom-reaction" aria-label="art reaction" aria-pressed="false" role="button" tabindex="0"><span>🎨</span></span>

Web Accessibility Specialist Certification

I’m not new to accessibility (a11y) but because it is not the focus of my job, I’ve had to do a lot of self-study to gain enough experience to consider myself proficient. Through the process of studying for this exam (and applying for a job along the way), I think I have finally found my passion.

I work in the United States for a large Canadian company in Ontario that is under pressure to comply with the Accessibility for Ontarians with Disabilities Act (AODA). It requires that websites updated since 2014 conform to the Web Content Accessibility Guidelines (WCAG) 2.0 Level A. Level AA is required by January, 2021.

At last year’s AccessU accessibility conference in Austin, Texas, I learned about the International Association for Accessibility Professionals (IAAP):

IAAP is a not-for-profit membership-based organization for individuals and organizations that are focused on accessibility or are in the process of building their accessibility skills and strategies. The objective of this association is to help accessibility professionals develop and advance their careers and to help organizations integrate accessibility into their products and infrastructure. The IAAP will provide a place for accessibility professionals around the world to gather, share experiences and enrich their knowledge of accessibility.

I heard they had a few certifications and I thought that would be a great way to test myself and perhaps come out with a credential that will help me in the future. The Web Accessibility Specialist (WAS) credential is where I started.

What is the WAS credential?

The Web Accessibility Specialist (WAS) credential is a technical-level credential for people who have hands-on experience with web technologies and accessibility. The exam assesses one’s web accessibility competence and takers are expected to know and use relevant technologies in a hands-on way, not just know about them. Per the IAAP, it’s ideal for intermediate level professionals (3-5 years’ experience) who have worked with WCAG 2.0 in context.

What is the WAS exam?

The WAS exam consists of 75 multiple choice questions with four options in the following content areas:

  • Create accessible web content – 40%
  • Identify accessibility issues – 40%
  • Remediate accessibility issues – 20%

The exam is pass/fail and administered by a testing service either remotely or in-person. I took it at a local testing center because I was worried about all the things that could go wrong remotely.

The exam is administered during a testing window for scoring purposes.

Preparing for the WAS exam

I reviewed the comprehensive WAS body of knowledge document which is a 20+ page overview of everything that could show up on the exam, from WCAG success criteria to testing with assistive technologies to recommending techniques for fixing issues. It’s a lot of stuff and honestly, I was pretty worried since I don’t work a job where I do accessibility evaluations every day.

I decided to study by going through a WAS exam preparation course offered by Deque University. I gave myself four weeks to prepare. My strategy was to cover about one content area per work day leading up to the exam. I took longer with those areas I had less experience in, such as ARIA widgets. I highly recommend this course and think it covered all the necessary subject matter.

My one piece of advice is to really practice using a screen reader and learn the common commands as two questions on my exam related specifically to hotkeys.

After the exam

They evaluate all candidates’ responses during the testing window and utilize a modified Angoff methodology and cut rate score exercise. Because of this, it takes a few weeks to find out if you pass. IAAP does not issue percentage scores or provide feedback on specific responses.

Three weeks after I took the exam, I got an email from the IAAP.

Congratulations!  We are pleased to inform you that you have passed IAAP – Web Accessibility Specialist (WAS) examination. Your hard work, study, and perseverance helped you achieve a significant goal – recognition of your skills and knowledge as a web accessibility specialist.

Per the email, just over 250 people have been WAS certified since the exam started in 2017.

IAAP web accessibility specialist certification logo

So what now? I am really  happy to have this certification and I know that going through this studying and exam process did a lot to get me used to looking for accessibility issues and communicating to developers how to fix them. I think this is a great exercise for anyone who wants a career in web accessibility.

IAAP WAS certificate for Rachele DiTullio awarded March 19, 2019.