I am working on a presentation for a dev conference and need to find a few more examples of what not to do when it comes to web accessibility. I have been scouring the web with my screen reader looking for bad experiences (I will add some of the screen recordings I've made here later.)
I'm happy I haven't found as many examples as I thought I would, but I haven't had as much time as I'd like to look. I would be eternally grateful for some help and
will share the final presentation at a later date.
💜 💜 💜
Top comments (13)
Please include stackoverflow.com in your examples. One quick run of aXe and it shows 888 color contrast violations, generic link text, skipped headings...lots of good results there.
You might have an easier time using a purpose-built tool since automated testing can catch a lot of accessibility problems. Deque's aXe or WAVE can even do everything in a browser extension (in the interests of full disclosure, I worked on the first release of aXe).
But my favorite broken website, although hardly major, is Yvette's Bridal & Formal. I love it dearly.
The accessibility advocate I saw a presentation from yesterday talked about aXe / a bunch of people talked about using it !
Thanks Dian! I use both tools from time to time. I'm mostly looking for good examples I can show in a screen recording. Many people have a hard time understanding the why behind accessibility, but showing them how awful a site can be to use with a screen reader or keyboard/witch helps a ton.
I went to a presentation the other day and an accessibility advocate demonstrated not just screen readers but a tool called a "Switch" like a one button tool for people with really limited dexterity. Maybe you have seen this before but when I saw in action I was pretty saddened because I just immediately intuitively knew huge numbers of websites would be incompatible with it :E
Sorry, realized not actually an answer to your question/maybe not fit for the presentation, but the demonstration was really powerful about UX and made an impact on me- watching the Switch zoom in on the button that is trying to be submitted. Basically if you rely on anymore than one button to submit a form it messes it up for people. My brain was like pow that is a huge number of websites.
I hadn't thought to add a switch demonstration, this is a great idea. Thanks!
The person who gave the Demo was Travis at this company: abilitrek.com/
My presentation on this topic focused on how people with disabilities use technology. Many developers and business decision makers don't get the "why" of accessibility because they don't use assistive technology or participate in the same usage patterns as people with disabilities.
For people who use keyboard navigation (low manual dexterity), a big problem I see is CSS overriding the default outline :focus style of the browser, so when someone uses tab to cycle through the interactive elements on the page, they can't see what is focused, and won't know what will happen when they hit enter.
On that same topic, the keyboard can't navigate to a custom "button," such as a span tag with an onClick event handler. The span won't receive focus, so someone using the keyboard can't activate that button.
Putting that in terms of a "BUY NOW" button that the user can't reach, I think is pretty impactful. Plus the number of ADA lawsuits for inaccessible websites tripled last year, so it's also a legal liability.
Custom buttons can recieve keyboard focus if they are built properly and implement the tabindex property on the HTML node and such.
I agree with your points, just figure that is a point worth clearing up - these things are often missed in custom elements, but can always be achieved.
You're right. The custom button element also needs a keydown event handler to respond to the user pressing the enter key while it has focus, and run the same code as the click event handler (or call click() on the element).
Keyboard accessibility can definitely be implemented on custom buttons, but considering how often it's not done properly (or at all), I figured it's probably easier for developers to just not do it. Thanks for mentioning this!
Another note, if the role attribute on a custom button isn't set to button it never appears in the accessibility tree. In general it's just a bad practice. I've never understood why someone would use a non-clickable element and try and force it to work as one anyway. Seems like way more work.
It sounds like we had very similar presentations! All of these are issues I see constantly on sites I review. Glad to see other folks taking notice and seeking to fix the problem.
For such an incredibly simple app built on HTML and minimal frills, Hacker News has a lot of accessibility woes.
Via Lighthouse: