Why I chose not to use an overlay accessibility widget on my website

This is going to be one of those real, vulnerable posts where the writer isn’t really coming from a place of experience and expertise – but of inexperience, trial, and error. Hi, it’s me.

Why talk about this? Well, I mean, I don’t really agree with only talking about the glories of running a business. I find people who are candid and sincere about what they’ve learned – and more importantly – what they’re currently learning to be really personable and valuable to engage with. 

Now, I have an opportunity to expose my experience behind-the-scenes, in hopes of opening up a greater conversation and continuing to learn more about web accessibility.

What is web accessibility?

Learning more about web accessibility and implementing it in my work is really important to me. It’s also intimidating and can be confusing when you use different tools, platforms, frameworks, and plugins.

Web accessibility refers to implementing specific methods of coding, design, and content in order to make your website accessible to people with visual or other forms of disabilities.

Who might use web accessibility tools?

Statistics Canada cited in 2022 that there are approximately 7.8 million people over the age of 15 who are disabled.

For example, individuals who utilize some type of web accessibility tool may be:

• Blind
• Deaf
• Dyslexic
• Neurodivergent
• and/or Epileptic

What impacts web accessibility:

• How a website is built (back-end)
• The color palette and fonts used (front-end)

Screen readers look for specific cues so that they can tell their user what elements, actions, and content is available on the screen. How a website is built – its structure, code, and formatting, all play into how it is interpreted by accessibility tools.

Colors and fonts (both in style and size) can have a huge effect on readability for those with color blindness, dyslexia, or visual impairment.

Maintaining descriptive alt tags on images and links will ensure that screen readers are giving their users ample information about what options are on the page.

What is an overlay accessibility widget?

In essence, an overlay accessibility widget is installed on a website to provide external third-party controls and settings that when used can affect the appearance of your website without changing your code.

This widget can allow the user to do things like:

• Switch from light to dark mode, or change background and font colors
• Make the font sizes larger or magnify the page
• Add focal highlighting to help the reader focus line by line
• Turn on the screen reader to read content aloud
• Utilize a keyboard navigation
• Limit motion and animations

What lead me to use an overlay accessibility widget

In receiving my own diagnosis as an adult it became painfully obvious the ways in which I struggled to meet standards or expectations that quite honestly never worked for me. Learning about my own needs made me more aware of what other’s might be and I want to do what I can to make their experiences less difficult.

This meant evaluating my own business, services, goals, and website. Starting with my website was crucial because it’s likely the first thing someone will see before connecting with me personally.

There are so many different website styles out there. Some are more design-focused with attention to how beautiful or interactive a website is versus whether or not that website is usable to all visitors.

The thought behind these overlay accessibility widgets is that you can install one within minutes without changing your design, layout, or functionality. So, on the surface, it seems like a cost-effective benefit while also being compliant to accessibility laws, and giving those with disabilities options to make their experience more accessible.

My mistake was assuming that these tools provide a thoughtful service that balances web design and user experience. Because on the surface, that’s what they appear to do.

When I started questioning using an overlay accessibility widget

Really, I have to thank the lack of communication and response from the company I used for my first overlay accessibility widget in leading me down this path. While I won’t name and shame, I feel it’s worth pointing out what can happen when you leave your customers to their own devices.

Of course the on-boarding and sale went splendidly. But as I started getting more correspondence from the company via email, it began to feel like everything I was consuming was one-sided.

There was a lot of marketing around accessibility lawsuits, the dollar amount that entities are held liable to be sued for, and the ease of installing the tool itself. I noticed that while their landing page initially talked about the user of the tool, everything thereafter felt more about what the tool does for the people who don’t need it.

Naturally, I had questions. Then began the weeks (and weeks) of receiving little to no response.

So, I started doing some digging myself, since nobody at the company wanted to talk to me (unless it was about reselling the product to my clients…) 

Why I chose not use an overlay accessibility widget

Mere days later, while I was googling my little heart out, a local UX company here in Edmonton that I respect very much, shared an NN/g article on the very subject of challenges for screen-reader users. This excerpt stood out to me:

 “To use an accessibility-menu screen reader, users must turn off the operating system screen reader they have been using up to that point.”

Tanner Kohler, Nielsen Norman Group

Much to my own lack of research prior to engaging with an overlay accessibility widget, I realized that the only information I had taken in from the view of an actual user was perceived in the marketing that third-party companies put out there.

I felt like my heart had been in the right place: I genuinely wanted my website to be user-friendly and here was a tool that I could install that would give users SO MANY options while engaging with my site.

Additionally, due to the very real and very necessary accessibility regulations that many regions have been or are beginning to enforce, there is some fear that if we don’t comply we could get into a lot of legal trouble. When given the option to install something to work around this, it initially feels like a good choice.

But a workaround didn’t feel like a solution.

“I hate [accessibility menus] because […] I think they make companies feel like they don’t need to actually work on making something accessible […] it is not a substitute for actual accessibility testing and, to me, it feels like just a Band-Aid that can almost make it worse sometimes.”

– blind user participant response in Nielsen Norman Group research study

I felt the quote “it is not a substitute for actual accessibility testing” in my heart. So, due to both not receiving any form of support from the overlay accessibility widget provider after being onboarded AND reading more about user experience, I pulled the plug and canceled the tool and my account.

I decided to start over and grade the accessibility of my website on its own.

What I have learned about overlay accessibility widgets so far

My overall takeaway has been that third-party overlay accessibility widgets primarily address legal requirements and accessibility standards for the website owner rather than focusing on actual customer and user experience.

Most users who require assistive technology to view websites already have their own tools, typically built into their operating systems or served via software, and these tend to work better than overlay accessibility widgets.

Automated repair

Of the overlay accessibility widgets that I’ve read about, I’m not convinced that automated repair is completely dependable. Considering the overlay is added to the site and the repairs are applied when the page loads in the user’s browser, I see room for unreliability.

• Repairs could slow down the site and increase page load times or cause unexpected layout changes. 
• Modern user interfaces may use javascript-driven controls that are independent of the overlay, making those unrepairable. 
• And what if the service itself goes down? There is a reason why hosting companies can’t guarantee 100% uptime and tell us it’s 99.9%.

Disabled users keep telling us: no thank you

In 2021, WebAIM conducted a web accessibility survey and asked: “How would you rate the effectiveness of web accessibility overlays, plugins, or widgets that automate accessibility changes in web pages?” 

The response: “A strong majority (67%) of respondents rate these tools as not at all or not very effective. Respondents with disabilities were even less favorable with 72% rating them not at all or not very effective, and only 2.4% rating them as very effective.”

Privacy concerns

This community-led documentation on overlays that I came across also outlines something that strikes me as important to pay attention to. Because what is the other big thing that people are talking about lately? Privacy.

An overlay accessibility widget may persist user settings across multiple sites that share the same feature by placing cookies on the user’s computer, although the user may have had no step to opt-out of that scenario.

Sensitive data should not be collected without consent, so there is also concern that an overlay accessibility widget may automatically detect the use of assistive technology, exposing the user at the time as having a disability.

How I made changes to my website for accessibility

As I began to look at steps to take to manage web accessibility without an overlay widget, I gained some insight on:

• Online tools that address on-site issues and general instructions on how to start remedying them
• What limitations or obstructions these overlay accessibility widgets can apply to a user’s existing screen reader

💡 Tip: I’ve included links to the resources I’ve come across at the end of this post, if you’d like to continue learning about web accessibility

I started my site accessibility research at the beginning of February this year. When I ran my first Google PageSpeed Insights report, my accessibility score was 95. Not bad. (To be fair though, this is only Google’s report and I do plan to use additional tools from user-centric accessibility guides.) 

Insights informed me that I had two main issues to look at in terms of accessibility:

• Names and Labels
• Navigation

The report let me know that the 3 social media links that appear in the footer of my website were missing discernible text and that the headings in my footer were not appearing in a sequentially-descending order.

Links must have discernible text

Users who rely on a keyboard (no mouse) to navigate a website can only click on links that have a programmatic focus, and screen reader users need to know when an element is interactive.

For these reasons we use what are called aria labels to define an interactive element. 

💡 Tip: ARIA stands for Accessible Rich Internet Applications. By adding Aria labels to HTML elements on a web page, they provide information about an element’s purpose and functionality to assistive tools like screen readers.

It’s relatively easy to insert alt tags and aria labels into blog posts and pages, depending on your knowledge of coding, or what website framework you’re using. Because elements like social links are so common, many frameworks have this functionality built-in, so instead of coding the link you simply need to copy and paste your social profile URL.

In my case, the framework didn’t automatically apply an aria-label to my social links, so I needed to manually apply them. Once I did, my accessibility score improved.

Heading elements are not in a sequentially-descending order

The purpose of heading levels (H1, H2, H3, H4, etc.) in HTML is to convey the structure of the page. Most frameworks will have default CSS in place that makes the font size for your H1 title larger than your H2 title. From there your H2 title will be larger than H3, and so on. This ensures that sighted users, at a glance, can denote the informational structure of the page.

Controlling only text size in this case obviously doesn’t work for screen readers. Instead, screen readers use the application of which heading tag you’ve selected to describe the structure of the page to the user.

This is why it is best practice to use an H1 tag only once, as your page title, and descend from there.

The problem with my site is that a headline title in my footer was set to an H5 tag with no previous H4 tags, and therefore wasn’t in a sequential descending order on the page. 

By changing all my footer title tags to H4, I improved my accessibility score.

Other best practices that might appear in your website accessibility report

I only had two issues to resolve to make my accessibility score 100% because I had already, for the most part, followed best practices when developing my new website. 

If you’re using a non-accessible premade theme or don’t have the working knowledge, your list may be a little longer. Some additional things you might have to look out for:

• Color contrast ratio
• Font sizes
• The presence of alt tags on images
• Aria label attributes matching their roles
• Button, link, and menu item elements have accessible names
• No hidden content
• Form elements have associated labels
• Heading elements appear in sequentially-descending order

💡 Font Size Tip: Make the smallest font size on your site 16px and go up from there. (Using em as your font size, instead of pixels, will allow your text to size dynamically rather than statically, depending on the size of the viewport your website is being rendered on.)

💡 Color Contrast Tip: Remember that color contrast doesn’t just matter on the web, it matters in your graphics and print materials too. If you have a brand strategy with your color palettes outlined, use a contrast checker to double check that your foreground and background color choices are compliant.

This is how I learned that my brand and favourite color (orange) is really not that easy to read in many cases.

The fact that I use orange sparingly now – and only on certain elements is absolutely due to seeing how poorly the contrast performs. This was a design decision influenced by accessibility.

Continuing to learn more about web accessibility

My plan moving forward is to spend more time learning about web accessibility and use grading tools that are made with the user in mind versus the mind of the website owner. I’ll be sharing my insight regularly so if you’re interested in following along, consider subscribing to my newsletter.

My goal is to be able to design and develop websites with the same level of knowledge I have with search engine optimization so that accessibility is also built right into my process: making websites for everyone.

Web Accessibility Resources

Below are links to some of the websites that I come across while I am doing my accessibility research, should you like to do some learning of your own.

Due to the nature of the topic I find that there is a lot of really helpful advice embedded within accessibility articles, through citing and the sharing of information from other references. 

Nielsen Norman Group: Screen Reader Users on Mobile
Link: https://www.nngroup.com/articles/screen-reader-users-on-mobile/

Overlay Fact Sheet
Link: https://overlayfactsheet.com/

WebAIM: Survey of Accessibility Practitioners (Overlay)
Link: https://webaim.org/projects/practitionersurvey3/#overlay 

Deque University: Links must have discernible text
Link: https://dequeuniversity.com/rules/axe/4.8/link-name 

Deque University: Heading levels should only increase by one
Link: https://dequeuniversity.com/rules/axe/4.8/heading-order 

Complianz: What are ARIA labels?
Link: https://complianz.io/definition/what-are-aria-labels/ 

Google PageSpeed Insights
Link: https://pagespeed.web.dev/ 

Chrome for Developers: Lighthouse accessibility scoring
Link: https://developer.chrome.com/docs/lighthouse/accessibility/scoring 

AccessibleWeb: Color Contrast Checker
Link: https://accessibleweb.com/color-contrast-checker/ 

W3C’s Web Accessibility Initiative (WAV)
Link: https://www.w3.org/WAI/fundamentals/ 

W3C is The World Wide Web Consortium, a non-profit organization of international groups who work together to develop standards for the internet.

Government of Canada: Understanding Disabilities
Link: https://www.canada.ca/en/employment-social-development/programs/accessible-canada-regulations-guidance/consultation/key-concepts.html 

WebAIM: Web Accessibility Laws in Canada
Link: https://webaim.org/articles/laws/canada/ 

To my knowledge, the Accessible Canada Act (ACA) regulations are currently only applied to government entities (including departments and agencies), Crown corporations, the Canadian Forces, parliamentary entities, federally regulated private sector entities, and federal public administration designated under subsection 7(3) of the ACA.

Because the conversation around accessibility, rights, and regulations is continuing to grow – and due to other regions enforcing mandatory compliance, I feel like it’s a good idea for every website owner to familiarize themselves with this information. 

The Admin Bar: Opening Links in New Tabs or Not
Link: https://theadminbar.com/accessibility-weekly/opening-links-in-new-tabs-or-not/ 

Ableism in Writing and Everyday Language
Link: https://www.rabbitwitharedpen.com/blog/ableism 

National Center on Disability and Journalism: Disability Language Style Guide
Link: https://ncdj.org/style-guide/ 

–

I very much welcome the feedback and communication of those who are more informed and willing to share their knowledge about web accessibility or their experience in living with a disability that can affect their navigation online. 

So please, feel free to email or dm me on socials if you have something to share, I want to learn to do better.