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:
- Web Accessibility Specialist (Glassdoor, Talent, ZipRecruiter)
- Web Accessibility Engineer (Glassdoor, ZipRecruiter, SalaryExpert-CA, SalaryExpert-US)
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.
