Web Accessibility Questions for Job Interviews

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:

Accessibility jobs on the rise

Reading Time: 2 minutes
People sitting in rows at computer workstations.
The image shows a shared open office space with many people working at workstations with big monitors.

When I finished writing the article about the Web Accessibility Engineer, I started to keep track of the links I posted there. Consequently, I noticed the information linked in there seemed to evolve over time. Hence, my curiosity led me to dig deeper into what other Web Accessibility Jobs could be found, or trending, for a Web Accessibility Professional. There are quite a bunch, and certainly on the rise.

This is great, it makes me very happy for newcomers and the new generation of professionals who join the Web Accessibility domain. For the most part, this work domain used to be a very lonely occupation before the year 2015. Or at least it was for me. That is to say, very few people could play along when implementing Web Accessibility.

To share the joy and for those who are interested, I will list and update my findings of Web Accessibility Jobs in this post. In addition to this, if you stumbled upon this post by chance and have a search string you want to share. Please do so in the comments. Do not post individual job positions. Only search strings.

Search strings and websites

All links below will open in a new tab.

Most common positions

  • Web Accessibility Engineer
  • Web Accessibility Specialist
  • Accessibility Consultant
  • UX Designer for Accessibility
  • Accessibility Lead
  • Accessibility QA
  • Frontend Developer – Accessibility
  • Software Engineer – Accessibility
  • Technical Writer – Accessibility

What is an Accessibility Engineer?

Reading Time: 4 minutes
A female accessibility engineer wearing headphones using a laptop computer.
The image shows a female software engineer wearing headphones and writing code on a laptop connected to dual monitors.

In short: a Web Accessibility Engineer is the person ensuring web technology is released accessible by removing the barriers that may prevent equal access for users of assistive technologies. This definition is almost the same as that of a Web Accessibility Specialist. So, how did this come to be?

In the beginning

Since around 2017, a vicious practice known as Predatory Litigation became a trend in the Web Accessibility domain in the United States. It consists of sending letters to companies, threatening legal action, or even filing suits. Alleging their websites are not in compliance with the ADA (Americans with Disabilities Act). Even when that law does not literally address Web Accessibility. Only places of public accommodation are mandated as accessible by the ADA Title III.

But once in court, it becomes a matter of law interpretation. This is scary for companies. Rulings over time have been consistently clear. Saying websites are an extension of a business, which are places of public accommodation. Therefore websites should be accessible. This phenomenon of “serial lawsuits” has caused federal accessibility lawsuits to exceed the 2,000 suits mark by 2018, and growing.

Most of the time companies don’t know the accessibility level of their websites, so they settle. Although the recommendation is not to settle. Mainly, if a website is already somewhat accessible, and being improved on what is missing.

Now, thinking that just because software is not public-facing things will be “OK” with accessibility is not accurate. Employees can sue too.

In the US if a company has more than 15 people, then employees can sue based on the ADA. Especially if the company recruits candidates with disabilities. If the users happen to be Federal Government employees, then it’s even stricter. Employees can sue based on ADA and also under Section508. The government knows this, so they will avoid buying non-compliant software.

In Canada, following Ontario’s AODA legislation (Accessibility for Ontarians with Disabilities Act) companies with more than 50 employees are required to make their websites accessible.

The Job Market Reaction

Litigation is the most expensive way to implement accessibility. Therefore, companies have started to recruit more candidates with Web Accessibility knowledge. Since 2018 a new role has started to emerge in job listings: Web Accessibility Engineer (WAG).

Before the WAG, there used to be the Web Accessibility Specialist (WAS). Very present in job listings too. Not to be confused with the IAAP WAS certification. It has the same name. The purpose of that credential is to validate the knowledge and skills required by the job role with the same name.

Now, by looking at the job description of both WAG and WAS I see many similarities. The only difference is that the WAG has more hands-on coding skills requirements. JavaScript (JS) for most cases. The salary also reflects this. Going from 10 to 40% more for the WAG according to internet pay scale sources. This varies by country and region. Here’s a quick glance:

In some of those salary links, it’s revealing to see under the WAG description that there are not enough reports to show salary distribution. I assume it’s still a very new job role as of 2019. Also, I see that WAG overlaps with the Accessibility Developer role. An interesting detail.

Usual Requirements

Regardless of years of experience. Removing the soft skills any professional should have. As well as the candidate’s good-to-haves, those change from one company to another. Removing all that, most job postings on the internet include the following as common qualifications for a Web Accessibility Engineer:

  • Experience with Accessibility Evaluation Tools.
  • Perform accessibility audits of web pages, desktop applications, and mobile apps.
  • Experience with Assistive Technologies across multiple platforms. Including Screen Readers, Magnification, and Read-aloud tools (e.g., VoiceOver, NVDA, JAWS, ZoomText, Dragon Naturally Speaking).
  • Experience with Mobile Screen Readers using gestures.
  • Write reports describing accessibility issues and recommendations for resolving them.
  • Write VPAT documents (Voluntary Product Accessibility Template).
  • Ability to prioritize accessibility issues.
  • Knowledge of Document Accessibility Remediation (e.g., Word, PDF, PowerPoint, Excel).
  • Provide Quality Assurance feedback.
  • Rapid prototyping to evaluate potential technical solutions.
  • Solid knowledge of WCAG Success Criteria.
  • Solid knowledge of WCAG Techniques and Failures.
  • Knowledge of Accessibility compliance for ADA, Section508, CVAA-255, ACAA, EN 301 549 and Regulatory Environments.
  • Understanding of the difference between Legal Compliance vs Accessibility Beyond Compliance.
  • Answer accessibility-related questions, through helpdesk tickets and calls.
  • Train new hires and clients in accessibility standards.
  • Proficient with HTML, CSS and WAI-ARIA.
  • Proficient with JavaScript or an Object-oriented language (Seems a must-have, for most Web Accessibility Engineer’s job postings as opposed to Web Accessibility Specialist’s postings).
  • At least one Accessibility Certification: CPACC, WAS, 508TT, CPWA (mostly optional).
  • Experience working directly with disability communities (mostly optional).
  • Knowledge of User Requirements for people with disabilities.
  • Understanding of the difference between Accessible Design vs Inclusive Design.

The Bottom Line

In conclusion, a Web Accessibility Engineer is a Web Accessibility Specialist who is also a Web Developer.

I remember the same thing happened with Frontend Developers. There were many role names for people who only knew HTML, CSS and jQuery. They were called UI Developers, Integrators, etc. They complemented PHP and Java workflows. That, was before JS became a full-fledged language. Then JS was a requirement, and the Frontend Developer role was coined. Then backend knowledge was added to the mix, and the Full-stack Developer role was born.

In my opinion, the same thing will happen with Web Accessibility jobs. They will start to change and adapt to the workflow. Job roles and requirements will evolve over time.