When many devs, testers, and authors first start listening to content through a screen reader, they are surprised to hear dates, pricing, names, abbreviations, acronyms, etc. announced differently than they expect. With the best of intentions (or branding panic) they may seek to force screen readers to announce content as…
Disclaimer: This post and the headline is my opinion. I provide verifiable facts throughout to inform that opinion. I am also not a lawyer, and this post does not constitute legal advice. The content reflects my genuinely held beliefs and opinions. My concern with AudioEye has consistently been with the…
Using ARIA instead of HTML is generally fine for content, layout, structure, and other static bits of a page. A <div role=”heading” aria-level=”1″> is the same as <h1> as far users and accessibility APIs are concerned. It is unlikely a user will ever notice the difference unless you use both…
Spanned table headers are not well supported across screen readers. While you can visually style these all sorts of ways to make the spanning clear, I am focusing on the programmatic outcomes. Which essentially means how they are exposed to screen reader users. This post uses only HTML <table>s. It…
Automated accessibility testing tools cannot test 100% of WCAG. This position is not controversial. Other than overlay vendors, no automated tool maker makes that claim. This is partly because WCAG is targeted at humans, not code, and so nuance and context apply. Free automated accessibility testing tools may have even…
There is a non-zero chance that WCAG Success Criterion 4.1.1 Parsing will go away in WCAG 2.2. This isn’t a problem for users, regardless of the problems it may pose for the WCAG process, ACT rules, automated testing tools, or ossified testing processes. The joke here is using an antique…
3 January 2025: This post is out of date. Read my post Updated Brief Note on Description List Support for the most recent results of testing. TL;DR: Description list support is generally good (with Safari being the outlier), even if you may not like how it is supported. This post…
It’s a dice advent calendar. I have no idea how five Platonic Solids and some D10s will carry for 24 days, but I am going to find out. Web developers around the world have for years given a nod to Saturnalia solstice Isaac Newton’s birthday Yule wassailing mummering end of…
TL;DR: Support for aria-readonly is nearly non-existent for the roles I tested. Should you need it, you cannot rely on it. You will be better off revising the pattern where you think you need it. For some background, the aria-readonly property: Indicates that the element is not editable, but is…
Now that it is a market differentiator to talk about accessibility in projects, that’s all many do — talk about it. In a sea of pop-dev noise, “accessibility” can be claimed with little risk someone will challenge it. If someone does, the response is often a fine balance between silence…
I ran a highly scientific and well-scoped Twitter poll (yes, sarcasm) to ask a question that has been in the back of my head for some time: When you see a claim that an automated accessibility testing tool finds X% of issues, what do you believe the word ‘issues’ means…
It’s 2022 and people are still afraid to use <fieldset> and <legend>. I understand the layout challenges can be frustrating, but swapping to an ARIA group role will result in a more inaccessible experience. A Solution Try this: <fieldset> <legend>Choose</legend> <div aria-hidden=”true”>Choose</div> […] </fieldset> legend:not(:focus):not(:active) { position: absolute; overflow: hidden;…