Web accessibility transcends being a mere technical requirement – it is a crucial ethical practice that promotes inclusivity and ensures equal access for all. It involves dismantling barriers to create a digital environment that caters to a diverse range of needs and abilities.
Adhering to web accessibility laws and standards is not only about legal compliance but reflects a commitment to social responsibility and fostering an inclusive online community. Enhancing web accessibility also significantly improves the user experience, making websites more user-friendly and understandable for a wider audience.
The evolution of WordPress and its accessibility initiatives, as experienced by Joe Dolson, demonstrates the large-scale impact of such improvements, benefiting millions of users and underscoring the vital role of accessible web design in today’s interconnected world.
Exploring the World of Web Accessibility with Expert Website Accessibility Consultant, Joe Dolson
I first met Joe Dolson at WordCamp Minneapolis in 2013, but his work as a web accessibility consultant goes all the way back to 2004. In addition to teaching the definitive class on WordPress accessibility on LinkedIn, Joe is part of the Make WordPress Accessible team.
It was my pleasure to converse with Joe about his wealth of experiences helping businesses, non-profits, individuals, and millions of WordPress users make the web more accessible to all. During our conversation below, we converse about:
- The joys and frustrations of working as a web accessibility consultant.
- The challenges of making WordPress core more accessible.
- The changing landscape of the web accessibility community.
- 3 simple things you can focus on today to make your website more accessible.
- Simple things Google could do to change the entire landscape of web accessibility.
- How you can get started working in the website accessibility field.
- The 1 web accessibility issue Joe would solve if he had a magic wand.
The Interview with Joe Dolson
Toby: Thanks for sharing your time and passion for web accessibility with me today. Let’s begin with your journey. How and why did you get your start as a web accessibility consultant?
Joe: I started my business as an independent web developer and consultant in 2004. This was a bold move, given that the extent of my experience was three years doing minor web design for the academic library I’d worked for at Macalester College. To be clear: I wasn’t employed as a web designer, but I managed to convince the administration that it made more sense to publish our student worker documentation as a website than as a printed document, and that became my responsibility.
In 2004, I’d moved to Rochester, New York, where my partner was doing grad school. Finding work in Rochester didn’t go particularly well, so I decided to start up my own web design and development business. But I also wanted to do something that I felt had a larger social impact than marketing or design. My mother was the executive director of a non-profit organization providing arts programs for people with disabilities, so I already had better than average awareness of accessibility issues in the physical world. With a bit of research, I found that the world of web accessibility was something that was grossly underserved, and my existing knowledge was quite valuable. Years later, I have never regretted my choice to learn web development from this perspective.
Toby: You’ve been deeply involved in the WordPress accessibility community for years as part of the Make WordPress Accessible team. Additionally, a quick view of your support of your plugins on wp.org clearly shows you are a deeply engaged developer on the platform. How has WordPress’ approach to accessibility changed over the years? Also, How has your work on the Make WordPress Accessible team changed your approach to consulting projects?
Joe: WordPress has always had some attention paid to accessibility, even from very early on. However, what was considered accessible in 2003 is radically different from what’s considered accessible in 2024 – like everything else, what’s possible has changed significantly. This is a place where the size and scope of WordPress makes change difficult – a decision that seemed reasonable in 2006 may be untenable now, but have backwards compatibility challenges that make implementing changes very difficult.
The WordPress approach to accessibility has had uphill and downhill moments throughout the time I’ve been involved. There’s a strong willingness to embrace accessibility, but not always enough attention to the distinction between “meets standards” and “is usable.” I would definitely say that there is more accessibility knowledge in the project now than there was 10 years ago. However, the project is also larger and has many more contributors – so very simple mistakes can slip through. The initial release of the footnotes feature, for example, includes a significant error with a return link that has no accessible name.
WordPress, overall, does a good job on micro-accessibility: ensuring that individual interactions are accessible. It does not do a particularly good job on macro-accessibility: ensuring that the overall product is consistent and logical. But, in my opinion, this is a problem that’s true throughout the project – not just in accessibility.
I’m not sure that participating in the team has had a profound impact on my approach to consulting projects. It has had an impact on my knowledge base when consulting on WordPress projects – I’m much more likely to be able to quickly pinpoint the cause of a particular problem and suggest a solution. However, the work I do in WordPress isn’t closely related to what I do in consulting, on the whole.
Toby: What is the biggest joy and also biggest frustration about pushing a super-big open-source project like WordPress forward towards your accessibility goals for the project?
Joe: There’s a lot of joy in improving a project that impacts so many millions of users. On smaller scale projects, it’s entirely possible that a very minor change to improve accessibility in an obscure feature will never be noticed. On a project at this scale, any change is likely to have an impact, and that’s satisfying.
But yes, there are certainly frustrations. There are biases that it can be very difficult to work with. For example, the entire structure of the block and site editor is biased towards the desire to make your editing palette look like the outcome. That’s inherently a visual bias – and it really doesn’t work for screen reader users, because screen reader users always see the underlying reality of what they’re interacting with. So we sometimes run into problems because developers are prioritizing the visual canvas without giving equivalent consideration to the underlying experience.
Another frustration is backwards compatibility. I love WordPress because I know that the code I wrote 15 years ago still works. But, as a core developer, it makes pushing change incredibly difficult. Any breaking change meets with huge resistance from extenders, users, and other developers. And they should have that resistance, because the backwards compatibility commitment is a promise, and shouldn’t be broken lightly. But it can certainly make some features incredibly difficult to change.
Toby: How has the local/national/worldwide community of web accessibility consultants changed since you got your start?
Joe: Well, there are certainly a lot more of them. When I started, it was a very small community. If you were in the community, you pretty much knew everybody else in it. For a long time, if I saw a new accessibility article published, I had almost always either interacted with or met the author.
Somewhere around 6 or 7 years ago (correlating closely to the sharp spike in website accessibility lawsuits in 2017), the number of accessibility professionals really started to rise. This also relates to the founding of the International Association of Accessibility Professionals, the first professional organization for accessibility practitioners, founded in 2014.
I don’t have any concrete numbers for this; but that’s when I started to notice it. More voices, more diversity, more conversation. It’s a great improvement. But it’s still only a tiny minority of the web development community.
Toby: Based on my conversations with web consultants, there seems to be a lot of confusion about what web accessibility actually is. For example, anecdotally, most web developers and designers I’ve conversed over the last few months with believe web accessibility is all about “text color contrast” and not much else. So I thought it’d be helpful to our readers to start with the most basic question: What is web accessibility?
Joe: Website accessibility is a best practice in development that ensures that all users are able to interact with your application. It includes good color contrast in text, but it also includes proper labeling and appropriate use of HTML.
At a high level, website accessibility is fairly complicated. But the low level is actually incredibly simple:
- Everything needs a name that describes what it does. If you have a link, the text should make it clear where that link goes. If you have a button, it should have text that clearly indicates what happens. Labels, alternative text, aria-label attributes – all methods of providing an accessible name.
- Use native elements for interaction. Buttons should be ‘button’ or ‘input’. Links should be ‘a href=””‘. Building an accordion? Put a button inside a heading; don’t just add a click event to the heading.
- Use HTML to structure your documents. Headings are there for a reason: they provide an outline of your document and give context for the following content. Don’t just use a heading because you want large text.
There’s a lot more to it than that; but if developers followed just those three guidelines, the web would be a much better place.
I’d like to draw attention to a study called the WebAIM million. This is a project to assess the million top home pages on the web and cull some accessibility statistics. They show that as of 2023, 96.3% of home pages exhibited obvious Web Content Accessibility Guideline failures.[https://webaim.org/projects/million/#wcag]
Toby: What is the biggest misconception about web accessibility that your consulting customers bring at the start of your engagements with them?
Joe: I have a very unique client base, so my answer to this question may not be super helpful for you. The vast majority of my clients are non-profit organizations focused in some way on people with disabilities. So my clients tend to be very realistic about accessibility issues.
The most common request that is based on a misconception, however, has probably been about accessibility overlays. The way this is asked by my clients may be different, because it’s usually something along the lines of “I see a lot of sites with an accessibility icon providing tools. What do you think about those and should we add one?”
My answer is always no, you shouldn’t. The best possible scenario with an accessibility overlay is that it can help make an inaccessible site slightly easier to use. If you have an accessible web site (which is why they’ve hired me in the first place), then they’re worse than useless.
Toby: Understanding that website owners’ time, attention, and money are important factors in pushing forward a web accessibility proposal, what is the best-for-the-buck web accessibility win a small business owner or small non-profit director might find on their existing website?
Joe: Every site has different needs, so there isn’t necessarily a single “best possible thing to fix.” There are some best possible things to check for, however – easy tests that can very quickly expose significant issues.
- Use the tab key to navigate through your site. Can you visually see where you are? Can you access navigation dropdown menus? This test exposes whether you have problems with keyboard accessibility.
- Using your mouse, click on the label for each form field. If it’s a real ‘label’ that’s properly connected to a field, then focus should move to the form field. If nothing happens, then your labels aren’t real, and screen reader users won’t know which field is which.
- Review your copy. Is it densely written, with long block paragraphs and complex sentences? Does it include links like “go _here_ to learn more about our company”? Rewriting your copy to use simpler language, bulleted lists, and have links make sense out of context can help a lot.
Toby: If you could waive a magic wand and solve a single website accessibility issue worldwide, what single, specific web accessibility issue would you solve and why?
Joe: Text alternatives. If I could make every image have quality alternative text, every video have quality captions, podcasts have good transcripts, and unnamed controls have valid text, I think that would make an enormous difference to equality. Even though that in itself doesn’t solve problems with operability – keyboard accessibility is still enormous – at least it would mean that users might be able to describe what they’re having trouble with.
Toby: It seems like Google has prioritized website speed above accessibility in their algorithm and public statements to date. In fact, I can’t remember a time they even mentioned accessibility in the context of SEO, even though Lighthouse provides an accessibility metric (not saying they haven’t mentioned it – just that it hasn’t been a public relations priority for them). I mean, if Google made a stink about accessibility being an important ranking factor in SEO, website owners worldwide would immediately jump to action to address accessibility issues on their websites. Do you feel like Google “gets it” when it comes to web accessibility?
Joe: I’m not sure it’s helpful to describe Google as a single entity. As of 2022, Alphabet had 190,000 employees. They have dozens of different teams doing accessibility in different areas of the company. The left hand doesn’t always talk to the 3rd-from-the-left hand, and may not even be aware that the right hand exists. I think that there are parts of Google that do a decent job with accessibility, and other places where they make some terrible decisions. But there’s just so much there that it’s hard to quantify.
I do think that if Google publicly stated that accessibility would yield prioritization for search, it would make a significant impact. Now, there are a lot of corollary relationships between SEO and Accessibility, so *some* aspects of accessibility already are influential, but it’s mostly as a side effect, with no direct impact.
I think that Google would potentially use accessibility as a metric if they had good enough data about it, but assessing accessibility via automation is not very complete. I’m not sure it would be responsible for them to promote a site based on good scores for accessibility via automated testing. Pages can absolutely achieve perfect test results in automation and still be completely inaccessible for real users.
Toby: Building on that last question, if you had an opportunity to converse with Google’s CEO about web accessibility, what specific data points would you share to convince them to do more to support important accessibility initiatives?
Joe: Well, I’d probably want to draw attention to the WebAIM million, which I’ve already discussed earlier. But this large-scale assessment is very interesting. It’s a large amount of data showing what kinds of issues automated detection is finding at scale; and it shows that the gap is really enormous. This is where Google could actually be extremely valuable. They’re already crawling and analyzing all of these sites – if they raised the profile of this subset of issues in site owner reports, it could make a difference.
Toby: As far as I can tell, there is not a single metric that accessibility pros point to that says, “You are in compliance enough“. Compare that to the way tools like Google Pagespeed and GTMetrix have given website owners a clear marker of success on the topic of page speed. For example, a web developer can promise, “I’ll get you an ’80’ on Google Pagespeed”, and everyone can be satisfied with that. Why hasn’t the accessibility community rallied around a metric for success the way the web speed community has?
Joe: I think that web speed is much easier to quantify. Accessibility errors differ radically in terms of severity. If absolutely everything on the site was perfect, but the ‘Complete Payment’ button couldn’t be used with a keyboard, then the site should not be considered accessible. It’s only one error, but it’s an error that breaks the entire function of the site for the user. If the same site was missing alternative text on every single product image, it would still be functional, but might have hundreds of errors. So which of those sites should be considered sufficiently compliant?
Differentiating between “problem A is completely broken, but not very important” and “problem B is just a bit broken, but mission critical” is a big challenge.
Add to that the fact that automated tools can’t test 70% of problems, and there’s also a problem of scale. Speed tests are very scalable. Accessibility is not. If the only way to get a good picture of the overall accessibility of a site is manual testing, then the investment is too high for most users.
Toby: I’ve conversed with a handful of local accessibility pros who absolutely hate the overlay technologies promoted by companies like accessiBe, Userway, and, perhaps, some of the functionality provided by your WP Accessibility plugin. Understanding that these accessibility overlays and 1-click solutions are not the perfect solution, where do you feel these overlays fit in the accessibility conversation?
Joe: First, we should divide the world of overlays into three groups that should be talked about separately, as they each have different positions in the overall scheme.
- Large-scale automated overlays that are trying to cover a very broad range of possible problems, like accessiBe.
- High-confidence overlays that cover only a narrow range of high-confidence issues, like WP Accessibility.
- Custom overlays, that are created to target specific problems.
The first group is the primary area that comes up, obviously. These plugins advertise themselves as using AI to solve problems, and frequently have marketing information that suggests that they can help you comply with accessibility laws and avoid lawsuits.
In my opinion, all of those tools have value as experimental projects. The idea of finding and fixing accessibility issues using AI is reasonable. However, the reality of these products is that they are nowhere even close to what they advertise. As active research projects looking to gather data, I can support them. But as a commercial product, I think that they’re best avoided. There is a lot of evidence that these overlays can make some user experiences worse, and that alone is enough to disqualify them in my opinion.
The second group, including my own plugin, should mostly be considered as stopgaps. The goal of only tackling high-confidence problems is that the overlay is really trying to limit itself to issues that it really knows are problems and can solve. There’s no AI, no guesswork. Hopefully, they’re never making anything worse. That said, they’re also extremely limited. Using them to temporarily fix a handful of problems while you work to fix the cause is fine. But, similar to the discussion about Google Lighthouse earlier, depending on them just means that you’re not addressing a host of other problems.
The last group is custom-designed overlays. These are intended for use in scenarios where you’re depending on 3rd party software that you can’t control or modify. In the WordPress world, that might mean that you’re using a page builder, and it has some known problems. You can report the issues and hope they’re fixed, but you don’t ultimately have any control. But you can write a custom JS overlay that fixes at least some of the problems for you. These require expert work to create, maintenance to keep them current, and in an ideal world, can be removed when the relevant 3rd party software is fixed. But in some cases, they are the only way to resolve certain problems.
So, to summarize, no overlay fits into the picture as an ideal, permanent solution at this time. They range from interesting experiments that shouldn’t be used in the real world to necessary custom fixes, but even the best case scenario is only permanent because some 3rd party isn’t fixing their own problems.
Toby: Building on the question above, https://www.siteimprove.com/glossary/accessibility-overlays/ says, “these (overlay) tools are limited in scope and do not constitute a full compliance solution”. However, the problem that well-intentioned web developers and biz owners are constantly running into is that “full compliance” is not defined anywhere in law (and “full compliance” as a concept seems to be openly debated by the accessibility community as well). In your experience, and in the absence of clear legal guidance, how does the web accessibility community currently define “Compliance”?
Joe: “Compliance” is generally defined strictly as “compliance with relevant accessibility laws.” That will vary depending on where you’re doing business. If you’re doing any business in Europe, then there are some specific guidelines laying out what it means – and it’s basically WCAG 2.1 at level AA, at the moment. If you’re in the US, and only doing business in the US, then compliance becomes a lot more vague. If you’re subject to Section 508 of the Rehabilitation Act or Section 255 of the Communications act, then there are once again explicit rules – but if you’re a restaurant on the corner of 1st and Main, those don’t apply.
And in that case, “compliance” becomes “whatever a judge will accept if you get sued.” Thanks for the clarity, Department of Justice. That could change, but for now, it’s what we have to live with.
The web site accessibility community almost uniformly interprets compliance as “conforms with WCAG 2.1 or higher at level AA.” Simply speaking, that’s because this is the standard expected in Europe, it’s the standard expected for the US government, and widely accepted as a reasonable bar to achieve to reach the majority of users with disabilities. It has long been the assumption that if the US does establish regulations governing accessibility standards, that these standards will be what they’re based on. But anything could happen.
Toby: Building on the question above, in the physical world, a city can point to a street corner that was physically altered to support a clear accessibility objective, and say, “Project complete”. However, in my conversations with accessibility pros (likely different from accessibility consultants), they seem reluctant to use the phrase, “project complete”. This well-meaning drive to web accessibility perfection, if I can call it that, has the real-world effect of discouraging well-intentioned biz owners and web developers from even starting accessibility projects. As someone who consults with business owners and non-profit leaders, how do you approach web accessibility project scopes and related conversations? Or put differently, generically-speaking, how do you define the deliverables on a web accessibility project?
Joe: First, I’ll say that when the city points to that street corner and calls the project complete, they aren’t referring to the street corner. They’re referring to the curb cut they just added or the audible walk signal installed. If they do more work on that corner, they also have to address accessibility then.
It sounds like what you’re describing is site owners asking a consultant to label their site as “accessible.” I’m actually completely willing to do that, as long as I also have control over every change that happens to the site. If they have access to their site, however, then I can’t say that.
The real world has much better definition of what a project is than the web does. The web, for better or worse, is a world where self-publishing is the norm. So when you hand over a project, you’re usually handing to people who have a lot less expertise on the web and on accessibility than you do. The project is still going; the site is still changing; you just don’t have any control over it anymore. (Or, you have less control, anyway.)
So any promise I make has to be within the scope of the project I’m doing. For consulting, that means that I can only make a statement about the website *exactly* as it is when I do my assessment. If it changes, then I don’t know that anymore.
The assessment can be complete; the remediation of that assessment can be complete; but websites are living, breathing projects, and they change constantly.
Even if the user isn’t working on their website regularly, I’m depending on 3rd party plugins – and am I able to promise that the next update of a key plugin will be as accessible as the last? I’d love to believe that the progression of accessibility was always forwards; but I know from experience that new releases frequently come with brand-new problems.
Toby: Every field has geeky “battle lines” drawn that are totally confusing to everyone outside of the field. For example, try explaining the “Gutenberg vs Classic Editor” debate to anyone who doesn’t do WP professionally. What is one such geeky and important debate that’s happening within the web accessibility community at the moment?
Joe: Sure! But don’t blame me if you’re bored before I finish the next sentence. Currently, the Web Accessibility Initiative is working on the next generation of the Web Content Accessibility Guidelines: WCAG 3. One of the big changes proposed in WCAG 3 is a change in the model used to assess color contrast. It’s been known for a long time that the current model is flawed; from a visual perspective, there are combinations that pass but are visually horrendous, and combinations that fail that look just fine. The new model being proposed is something called APCA, or Advanced Perception of Color Algorithm. While the need for a new algorithm is accepted, the fine details of how this does and should work, and whether the increase in complexity for testing is worthwhile in order to have more accuracy are significant topics for debate.
To give an extremely brief summary, APCA acknowledges the fact that background and foreground colors should not be treated the same; and takes font weight, size, and family into consideration.
Toby: What advice can you give an experienced web developer who is curious about transitioning to a career as a web accessibility consultant?
Joe: In order to get a job as an accessibility consultant, you’re either going to need a long history of experience in accessibility or IAAP certification. I don’t have IAAP certification, but that’s pretty common among those of us who had already been doing accessibility work for 10 years when the IAAP was founded – but now, it’s likely to be a starting requirement to find work.
So you’ll want to start by taking training courses in preparation for their tests.
But those tests are not going to be sufficient to perform well in a real environment. You’ll learn a lot of foundational material, but you are going to end up with a lot of gaps when it comes to the real world.
- Watch videos of people with real disabilities interacting with the web. The WP Accessibility Meetup provides a lot of those. You can watch their videos at the Equalize Digital YouTube channel.
- If you can, work with people with disabilities to talk to them about their experiences on the web. Human feedback is priceless in understanding the impact a problem has.
Toby: If you had to choose, what is your favorite type of web accessibility project to work on these days? Why is that your favorite?
Joe: Well, I enjoy my client projects, because the people I’m working with are passionate about the cause. I love that I don’t have arguments with management who insist on designs with inherent accessibility problems, or with developers who are unwilling to make needed changes. Most of my primary client projects are development and consulting – I both build their sites or applications and I provide feedback on accessibility issues. That gives me a pleasant mix of tasks.
I still do consulting-only jobs, but – in all honesty – they’re not my favorite. Assessment alone is an exhausting job, with a lot of details to track and verify. Going through the same workflow 20 times on three devices using different AT combinations can be incredibly tedious…
Toby: Anything else you’d like to share?
Joe: What, isn’t this enough already? ?
But seriously, thanks for inviting me to answer these questions. Some of them were topics I hadn’t really given a lot of active thought, and they were worth considering.
I guess I want to share my WordPress Accessibility course on LinkedIn Learning – if you want to get an overview on building and testing accessible WordPress websites, that course will give you a good background!
- Joe’s WordPress: Accessible course on LinkedIn Learning
- Make WordPress Accessible
- Learn more about Joe’s consulting services and WordPress plugins on JoeDolson.com.
- Joe on WP.org