Accessibility Auditing is Harmful for the Web: A Clarion Call for Systemic Change in Our Approach as Accessibility Advocates and Auditors35 min read

Introduction

A. About Me

Following my 6 year stint in the US Navy during the Persian Gulf War as a Nuclear Reactor Operator (1992 to 1998), I achieved a BS in Computer Information Systems (computer programming) an additional AS in Computer Networking Technologies (1999 to 2002). During college, I started to learn web development on my own starting from HTML for Dummies and Hakon Wium Lie‘s Cascading Style Sheets: Designing for the Web (1999) and then, once I graduated and started my first job in January of 2003, I drank deeply of the web development wisdom that was available online.

As a part of that journey I joined the movement of Web Standards Developers, and found out about and fell in love with usability and accessibility. I was a member of Russ Weakley‘s Guild of Accessible Web Designers (GAWDS) as well as the Web Standards Project (WaSP), before they all eventually closed down by 2015. I also became a Certified Usability Analyst (CUA, 2006) through Human Factors International (HFI) during that time too. I have been passionate about web accessibility and usability for almost 20 years.

However, with my previous job of 19 years ending due to cost cutting (Dec 2021), I decided to dive headfirst into what I am passionate about – accessibility – which is what I have been doing since then. I became a member of the International Association of Accessibility Professionals (IAAP, Dec 2021) and then studied for and passed their Certified Professional in Accessibility Core Competencies (CPACC, Mar 2022) with Above Average in all 3 areas, and then also attended Axe Con in March 2022.

During these last 4 months I have done some freelance auditing while looking for work in this field. Fortunately, I have just found an amazing position with Western Governors University as a Digital Accessibility Expert. That is their label, not mine! =)

Ok, enough about me and my journey into Accessibility, and where I find myself now. Now, onto what this post is about.

B. Post Overview

During these last 4 months of looking for work, in most of my second round interviews I had lamented about the state of web development education which has lead to the state of the significantly inaccessible web that we find ourselves wading through today. I can pretty much guarantee that only a small fraction of websites actually meet AA of the WCAG 2.1 (Web Content Accessibility Guidelines) if it is applied stringently. And, this is sad to say especially when creating accessible web content is NOT at all hard. It really isn’t. The horrific state of the web persists today because of the abject failure of our web development educational paths to teach development correctly – with compassion and inclusion as a foundational principle for ALL web work.

This post will go over the issues with accessibility auditing as an industry standard, and I will make a call for larger order systemic change in the industry, so that we can solve the web’s accessibility issues relatively “quickly” – in five or so years.

This post will have 4 major sections:

1. The Harms of Accessibility Audits
2. Naming and Shaming Inaccessible Site Building Tools
3. The Clarion Call For Systemic Change
4. An Accessibility Driven Work Force

…so strap yourself in, accessibility peeps.
Come for the article, but stay for the memes. =)

I. The Harms of Accessibility Audits

Introduction

In this section I will make the case that accessibility audits do not serve the client, nor do they serve the internet, nor do they broadly serve those with impairments in the long term. The key here is long term.

A. An Accessibility Audit is a Company’s Web Developer Competency Test

Let’s get down into what an accessibility audit really is in stark and brutal terms: accessibility audits are really a web developer competency test which ends up with us (auditors) just telling our clients that their developers have no idea what they are doing and that they are writing shitty code which may put their business in legal danger, as well as fostering a image for their business that they do not care about an inclusive web or being an inclusive business which could be a PR shitstorm. If you are a business owner and lawsuits are your kink, then hey, you do you, ’cause I am not here to kink shame; but, for the rest of us, this potential should be horrifying. If developers knew what they were doing and created accessible websites then we accessibility auditors would not have a job.

The following link is harsh, but accessibility people and people with impairments may be able to sympathize: WCAG 2.2 Draft Criteria Proposal 6.1.1.

B. Audits Potentially Create an Antagonistic Work Environment

When we send developers a page by page audit this can create a low level antagonism not only towards us as accessibility professionals who are just trying to help, but also to the client’s management, and their developers’ management. These changes we recommend to the already overburdened workload of the unrelenting web development industry can radically increase the level of stress for all involved. This may potentially make everything else within the industry harder than it has to be.

C. Audits Can Result in Client Complacency

Audits are a stop-gap for clients and their developers’ incompetence so they can say that they are working towards making their website accessible (since they failed to do it right the first time) to hedge against potential lawsuits. They contact an accessibility company so that audits can be performed, and to have the accessibility company’s logo in the footer, hoping to dissuade anyone from suing. This is also used as a way to say “See! We are working on it. It is not our fault. It is the accessibility company’s fault. They did not tell us!” or “It is a long process, so be reeeeealy patient!” and so on, even though their site never should have been broken in the first place. With this sort of public signal out there, they believe they can take their time to fix things or blame the lack of change on the developer’s work load or some other bureaucratic or fiscal issue. And, then keep delaying making the real changes required to ween themselves off the accessibility company’s auditing and expertise by cultivating their own.

D. Barely Incremental Change with Recurring Errors

Accessibility is NOT extra steps.
Accessibility is the steps your forgot to take.

someone on Twitter

Monthly audits as a primary means of helping to improve a site’s accessibility is barely incremental month by month change. They are barely placing a band aid over a gaping stab wound, while the attacker is still stabbing away (developers continuously NOT coding accessibly). The site’s developers may fix an individual issue, but they may end up making that same coding mistake again because they do not understand why it is a mistake, nor do they care, nor do they have the foundational knowledge or empathy to understand or want to remember. Such knowledge is not ingrained into them to care or to understand, because they do not see the web through the eyes of inclusion and empathy. They just want to get this extra work done, so they can get to their coding backlog.

Audits are done instead of providing an answer which is larger and more sweeping (systemic change) which could more quickly speed the client towards reforming their website and creating an accessible developer pool as soon as possible.

E. Wasted Time on Random Page Audits

Also, if random pages are audited every month, then there can be A LOT of wasted time because the same issues are still present there month after month as the developers slowly fix things which ends up wasting the accessibility firm’s time and expertise, as well as everyone else’s time from having to look at so many duplicate error reporting. If a product page was analyzed thoroughly before and everything was found, and there are no new areas added to a product page, then the only thing that should really be done with those product pages is testing fixes to the page unless there are major structural changes made to that page type. Although, a quick check on the content’s structure would be OK.

F. Audits Serve Profits Mostly

Audits serve the auditing businesses’ profit margins because it creates a continuous stream of perpetual work, because the client’s developers do not change how they code in the long term, so there is very little incentive for an accessibility business to cure themselves of this plague of auditing as long as it could mean a loss in profits. Yea capitalism! =(

G. Accessibility Audits are Still Necessary

However, as an accessibility auditor, let me say that I do not think we should stop doing them, because they are a useful tool to have in our toolbox to help ensure that the web remains as accessible as possible, but they should NOT be the primary means for our work towards effectuating large scale change within the web, because they are at best temporary incremental change to help jump start our clients’ learning process. The ideal goal that ALL accessibility businesses should have is to work themselves out of business, and accessibility audits are NOT ever going to be a tool to accomplish this.

II. Naming and Shaming Inaccessible Site Building Tools

A. These Are Just Medium Term Patches

The below options are not perfect and have the same issues as audits have from above (because you are really just auditing their software) which are: sure your fixed those issues, but then their coders may make those same types of errors again. These are more of medium term patches, which would lead us to the real solution in the next section.

B. Focusing on the Client’s Web Tools

Here are the steps for this:

1. Find out what CMS your client is using as well as what themes, plugins, and modules, etc… they are using.
2. Publish a blog post:
   1. Name and shame the CMS (if needed) and the broken, themes, plugins/modules, etc…
   2. List what accessibility issues there are with each.
   3. Provide the solutions to fix all of the present accessibility problems.
   4. File the appropriate bug reports to have them fix the accessibility issues, and continue to monitor those bugs.
3. Volunteer to help them solve the issue, so you know it will get done.

Such naming and shaming will generate a lot of talk about accessibility within the community as well as awareness about accessibility issues. And, once these accessibility issues are fixed, this will increase the accessibility of all sites using that CMS and those site building tools, as well as for your client specifically.

C. Focusing on the Most Popular Tools

You could also publish that same type of blog post as mentioned above but focusing on the most popular modules/plugins for a given CMS in a given area such as breadcrumbs, and then write a blog post tearing apart the accessibility issues for the top 5 of them, rating them, and then file bug reports to get those issues fixed. You can similarly volunteer to fix the issues too.

By concentrating on CMS’es and their site building software you change it not just for your client, but also for ALL of the people who are using that site building software’s tools too. There is a large bang for your buck to effectuate broad scale change quickly through this method of naming and shaming, and assisting in the fixing of their code.

D. Dedicated Open Source Programmer on Staff

Honestly, each accessibility shop should have at least one open source developer on staff just to do this full time. Hell, you could start an open source project just so you can collaborate and not waste anyone’s time. If every accessibility shop did have one open source programmer on staff then, in short order, much of the accessibility issues on the web could be fixed fairly quickly, while powerfully supporting an open source internet. Everybody wins!!

III. The Clarion Call For Systemic Change

Introduction

Hopefully, in my thoughts above I made a decent case for why accessibility audits are limited in usefulness, and barely qualify as incremental change. They are mostly useful for auditors like myself to keep their auditing skills sharp, and that is about it, really. This then begs the question: What will provide long term value for the client’s buck and to push the internet at large quickly to a more empathetic and accessible space? Any long term solution to this inaccessible internet issue must be looked at through the lens of systemic change, because the system is the problem. If we do not change the way sites are developed then we will just end up spinning our wheels in place while never really accomplishing anything.

First, let’s look at what systemic change is: “Change has to be fundamental and affects how the whole system functions”. We need to look for a solution which changes the way the whole web development system operates so that it no longer creates inaccessible websites.

This quickest way to serve our clients and the web quickly is by power-driving their developers and their development model straight into an accessible development shop. Anything short of this is wasting a lot of our precious time and resources, and has people with impairments needlessly suffering while trying to get things done on the web.

A. The Failure of the W3C to Lead on Accessible Web Developer Training

Let’s take a look at what the W3C offers as web developer educational paths. On a quick look I see two options:

1. W3Cx (Training) – On the bottom left of the sidebar there is a section labeled as W3C Developers, and below that there is a link to W3Cx (Training), and that takes you to some light intro open courses including one for accessibility, which is a good start, but barely a start.
2. W3C Front-End Developer Professional Certificate – And then at the bottom of that above mentioned training area there is a link W3C Front-End Developer Professional Certificate which is for ~$900 where accessibility is barely a foot note which is criminal. Accessibility is no where near the star of the show that it needs to be.

Honestly, for all web dev courses, the Web Accessibility course should come first and be required to be completed before unlocking the rest of the course work just to show how important it is to their work and learning.

Now, don’t get me wrong, the W3C is a non-profit and they are busy creating specifications, and all of that. But, they already created a course (or two). They already have the experts and the accessibility materials through the Web Accessibility Initiative (WAI) and so on. How hard would it be to make accessibility as the first and most important part of each course? blink blink I know. It wouldn’t be hard at all.

Do you want to know why the web is an morass of ableism and inaccessibility? This is why!!! Can you sense my barely contained rage? I hope so. Ok, whew! I will simmer down now a bit and get into how we can work towards fixing this ridiculous and criminal oversight of the W3C.

B. Create an Accessible XHTML5 Developer Certification Path

Introduction

Since the W3C is criminally remiss at not having implemented something like this, then we will have to create a training and certification path for a Certified Accessible XHTML5 Developer (CAX5D) ourselves, which should be available online for free so we can have it available to create a global pool of developers who can code websites accessibly.

Once a course like this is created, you can then give this to each client for their developers to go through. Also, offer this to each and every educational institution which teaches web development. Then start naming and shaming schools which do NOT teach web development from the standpoint of accessibility and XHTML first, because that is where this inaccessible web problem started in the first place. Doing this will create a huge conversation through the controversy, but could effectuate change quickly once the schools pickup this new program.

Now, what might such a curriculum look like for the beginning of a full time class load (or something like that)? I will give you a rough outline of what I think we could do, from my limited view, so take this all with a grain of salt. There is so much more than this, but this should get you a good start on how I am thinking about this and how we solve the long term problem. We will look to start small and then build up and layer their skill set and empathy as we go.

The curriculum will be broken down into 4 basic sections:

1. Accessibility Foundations – Learn about accessibility and why it matters. We must also work towards powering up their empathy too.
2. XHTML5 – Semantically correct, valid, and well-formed XHTML5 is the bare essential for accessibility, plus we will start to have their minds thinking like auditors by judging the semantic correctness of code.
3. Accessibility Tools – Introducing them to the WCAG and ARIA so that they know what it is, read through some of it, and then start talk about auditing websites for accessibility issues
4. Accessible Web Development – Just continue on teaching with these fundamentals in mind (empathy and accessibility; semantically correct, valid, and well formed code; separation of layers; progressive enhancement).

Keep in mind that this is all a very rough outline, especially towards the end. We will need both the teachers side of the course and the students side of these courses too. We will also want to take into account Universal Design for Learning principles as we are putting all of this together.

1. Accessibility Foundations (month 1)

Introduction

We will start with making the case for accessibility and instilling empathy into our developers of tomorrow, because this is the piece that is sorely lacking, and this IS the foundation for web development.

This process will fall into 4 different sections:

1. Empathy and Accessibility Foundations
2. Secondhand Accessibility Experience
3. Firsthand Accessibility Experience
4. The Case for Accessibility

a. Empathy and Accessibility Foundations

A good place to start is to use the International Association of Accessible Professionals’ (IAAP) Certified Professional in Accessibility Core Competencies (CPACC) test content, so that our new students will know why accessibility matters. This Body of Knowledge will form the foundation for their learning process.

b. Secondhand Accessibility Experience

Second, sprinkled liberally throughout this learning process students should be watching plenty of videos of how people with the various impairments experience and use the web.

If we can, bring in some people with impairments to come in and use the web live for the class and to answer questions for them about their web use and their experiences with disability.

c. Firsthand Accessibility Experience

The third part is to have the students experience firsthand the frustration of the inaccessible web for themselves. The curriculum will need curated sites, some of which are broken and some which are not, so that they can experience both sides. They will be given tasks to perform on each site.

1. Have students perform tasks on various websites with keyboard only (no mouse).
2. Have students, while blindfolded or with the monitor off, perform tasks on various websites with keyboard and screen reader only.
3. Have students perform tasks on various websites with the sound turned off.
4. If we can get access to other assistive technology for the students to try that would be powerful too (sip and puff, switch access, voice activation).

This should be enough to get their brain into thinking about accessibility, why it is important, as well as supercharging their empathy too by:

1. First, seeing people with impairments use the web.
2. Then, talking with people with impairments and learning of their experiences.
3. Lastly experiencing using the web with assistive technology themselves.

It is harder to deny the issue of an inaccessible web if you have experienced it yourself, and if you have to keep experiencing it. This whole process will also introduce them to how important and fundamental a test that tabbing through the page really is.

d. The Case for Accessibility

The fourth part will be teaching them the various excuses stakeholders provide for not doing accessibility, and then providing our students with the break down for why the stakeholder’s excuses are incorrect, and how to refute them. Arming our future accessible developers with the ability to combat the primary stakeholder blockers for accessibility is perhaps one the most powerful and valuable tools we can provide them. This will also help to instill into them that there is no reason to not code accessibly.

2. XHTML5 (month 2)

In this second phase we will introduce the students to the HTML5 specification as well as making the case for why creating:

• semantic
• valid
• well-formed

… XHTML5 is the foundation of accessible web design. Because, without semantic, well-formed, and valid HTML5 there is no accessibility; or, at least, your work to make an accessible website is potentially made more difficult. If we can drive this into them then we are almost there in creating a new wave of accessible web developers.

Here is a question from Axe Con 2022 to Mark Steadman: “Should I learn semantic HTML or ARIA first?”

Holy hell! Learn semantic HTML first.

…

I can tell you right now, semantic HTML will save you loads of time. It will.

…

But, also it will save you from getting into the weeds of having the worst experience with ARIA. So many things I see in the field are people who will put ARIA on everything and they end up in a pretty messed up web of ARIA. And, it’s hard to get back out that.

If they would just use semantic HTML in the first place, right, in tandem with everything else they’ve got, they will be in great shape. Use semantic HTML. Learn it, because it has so many built in accessibility options already there. Use it and learn it.

Mark Steadman from his presentation titled Starting Your Accessibility Journey: A Developers Guide at Axe Con 2022 (question @ 37:45)

We will have the students read through a few of elements within the HTML5 specification so that they know that the specification exits and where it is, what each element is used for (its semantic value) and how it should be used:

• headers
• paragraph
• ordered and unordered lists
• image

We can then introduce them to sample HTML5 code so they can see these elements in action, and then look at how different sorts of content might be formatted using these elements to get their brains thinking about semantics, and perhaps even wanting other elements with different semantic meanings to mark their code up with. We will also work with them to validate this code and to look for well-formedness errors so they will start thinking about code quality.

Lastly, we will have them take a look at the HTML5 code behind various websites to check for how semantically correct their code is (a semantic code audit). This will get their brains thinking about semantic HTML5 and to be critical of their code, all of which is are very important tools to start instilling into them so that we can begin their journey into becoming an accessible XHTML5 developer, and for having them to start developing their auditing brain.

3. Accessibility Tools (month 3)

a. Web Content Accessibility Guidelines (WCAG)

Now, we will continue the discussion about XHTML5 by introducing some the landmark elements, and then have the students read the HTML5 spec for these elements. We can show them that screen readers can navigate by jumping from landmark to landmark, and from header to header, and then have them do it too. We can spend some time auditing some sites for landmark roles.

To reinforce the things that we have already been teaching them, we will now introduce the WCAG 2.1 by giving them a link to it, going through the basic parts, and then introduce a few criteria for them to digest:

• 1.1.1 – Non-text Content – for those with visual impairments
• 1.3.1 – Info and Relationships – semantically correct code
• 2.1.1 – Keyboard – keyboard only accessible websites and screen reader users
• 4.1.1 – Parsing – reinforces valid and well-formed HTML/XHTML

This will hopefully have them start to see how this all ties together. We can show example code and have them audit it for these criteria. We would then explain why the WCAG is important, how to understand it, how to test it, how to code for it. We will also have them evaluate websites for semantic HTML and
evaluate websites for accessibility using the WCAG.

Once you start getting into actual code, you will review the code’s semantics and any applicable WCAG criteria or usability issues that may come up.

b. Accessible Rich Internet Applications (ARIA)

Only using Accessible Rich Internet Applications (ARIA) when necessary. Potentially, if you are using ARIA then you may be doing something wrong. Check what you are doing to see if there is a more semantic way of doing it. Although, there are a few places where ARIA is needed because there are no native HTML elements which cover such as:

1. in-page tabs
2. carousels (please, just don’t use these)
3. live regions

We will want to introduce them to the appropriate accessible design patterns for these exceptions, and have them test them too so they know how well they work or don’t.

Accessibility Lipstick on a Usability Pig (WebAIM)

4. Accessible Web Development (months 4+)

a. Separation of Layers

There are 4 parts to a web page:

1. Information – the page’s content – A webpage is there to show us information in one form or another.
2. Structure – HTML is the structural layer providing semantics to describe what the content is and to describe the structural aspects of a page’s layout.
3. Presentation – CSS is there to provide the presentation and layout.
4. Behavior – JavaScript is there to create the website’s client facing behavior through scripting.

The structure, presentation, and behavioral layers should maintain as much separation as possible – no in-page CSS or JS. It should be as separated into their own files as much as possible. Clean HTML is easier to troubleshoot, and see what is going on then having to wade through tons of inline CSS and JS.

b. Progressive Enhancement

As as stepping stone to the Separation of Layers, we have Progressive Enhancement. Once you first have created your page by adding your content with semantic XHTML, then you look to add CSS and, in doing so, you should make sure that the site works just fine like this (without JS). Then you look to add JS behavior. At each stage (HTML only, + CSS, + JS) the site should be functional.

c. The Rest

Then you get into the weeds as far as web development is concerned – blending XHTML, CSS, JavaScript, but still all taught through the eyes of accessibility, always through that lens. Perhaps, the last half of each Friday will be semantic and accessible code audits for not only the students’ code, but on other websites too. They will still use screen readers or other assistive tech. For each lesson, the links to the HMTL5 spec for the new individual elements will be listed and be a part of the required reading. Also, the applicable WCAG criteria shall be listed as well as which impairments are the most effected by these tags or the project being worked on. We can also introduce accessible design patterns here too.

C. How Do We Get Businesses to Make the Switch?

How do we get businesses to make the switch to compassion, empathy, and inclusion? That is a good question. Here are some thoughts:

1. Naming and shaming is a good start.
2. Grants for businesses to have their people go through this accessibility training.
3. Having governments pass a law which gives a small tax break to those businesses who have very accessible websites would be a great reinforcing driver.
4. Having governments pass a law which gives an increase in taxes on those businesses who have significant accessibility issues with their websites, in addition to fines.
5. Having the government step up or start to do website auditing and then file complaints against the businesses with inaccessible websites.
6. Businesses with inaccessible website cannot qualify for government contracts.
7. The government could also be a registry where people can find businesses with accessible websites to work with, or to know which ones are having issues too, so that they can avoid them if needed.
8. Businesses which are accessible could also require that anyone that they do business with should have an accessible website.
9. The W3C can keep a list of all of the education institutions that are using this curriculum, so that students know where they can learn web development correctly.

Conclusion

Will we put most web dev training companies out of business by doing this? Hopefully not. Hopefully, with a naming and shaming campaign they will pick up this program which would be a good thing. Having the training to create accessible websites as open and free contributes to making sure that the web is as open free, and as accessible as possible, and it makes it so that anyone can learn it and learn it correctly, if they have the time and inclination.

Honestly, and to be completely harsh here, the fact that the W3C has not done this with all of the expertise that they have available is bordering on malpractice. They should have put something like this together and posted it to a least one MOOC site. This would save the internet so very many problems, especially if there was a certification for it too.

IV. An Accessibility Driven Work Force

Now, I am going to be real with you. If your company is really into inclusion and accessibility, then your company should join the International Association of Accessibility Professionals, and then every… single… person in your employ should take an Accessibility Foundations sort of in depth course. If every single person in your company is not thinking about empathy and accessibility, then this may end up being problematic.

Once your people get through the first part of the training, then you can have their training diverge from there as it applies to their specific work, such as something like this:

1. Accessibility Foundations (IAAP’s Certified Professional in Accessibility Core Competencies) – a course like I outlined above
   1. Accessible XHTML5 Developer – This is what we need to create as is listed above.
   2. Creating Accessible Digital Documents (IAAP’s Accessible Document Specialist)
   3. Creating Accessible Web Content – I have written training on this, but need to reframe it for a more general audience.
   4. Accessible IRL Spaces (IAAP’s Certified Professional in Accessible Built Environments)
   5. others?

A company that did this whole-heartedly would really create waves globally and perhaps even set a new standard for what an inclusive work place really is.

Now, after reading the above, ask yourself this “How inclusive and accessible is my work place, really?“.

Conclusion

Accessibility Audits are going to be a necessary evil until as such time as the accessibility community focuses on creating a one stop open and free educational shop for colleges, universities, and individuals to learn web development through the lens of accessibility, so that someday, sooner than later, that accessibility auditing will be relegated to an as needed thing.