What web accessibility actually covers (1m03s)

Ire opens by widening the usual frame of "accessibility = screen-reader support" to include situational disabilities (the one-handed user holding a baby) and socioeconomic restrictions (data-conscious users on expensive mobile connections). The WCAG four principles — perceivable, operable, understandable, robust — are the standard reference.

"this is about making websites accessible for everyone"

"accessibility also refers to how people with socioeconomic restrictions can access websites"

"if you are from a certain country and you are gonna be extremely data-conscious, that might limit what types of websites you can actually have access to"

HTML is accessible by default — CSS and JS can break it (4m09s)

A plain-HTML page passes nearly every accessibility check by default. The 90/10 framing: 90% of accessibility is using HTML correctly, the other 10% is not using CSS and JavaScript incorrectly.

"by default HTML is accessible, so a lot of the work of web accessibility is more about ensuring that it actually remains accessible"

"if you have just HTML, it's pretty good on its own — but when you add CSS and JavaScript, it kind of starts to really mess things up"

"90% of accessibility is about using HTML correctly, and then the other 10% is about making sure you don't use CSS and JavaScript incorrectly"

The accessibility object model (5m43s)

The render tree is what users see (DOM + CSSOM). The accessibility object model is what assistive technology sees — mostly built from the DOM alone, with each interactive element's name, role, state, value. The implication: information that exists only in CSS isn't reaching the user with a screen reader.

"what's important to note is that these two elements, HTML and CSS together, form what is the render tree... but when we're talking about what assistive technologies or user agents see, it's actually not really all of this — it's actually mostly just HTML and the DOM"

"the accessibility object model... has information like the name of the element, what its role is, the state it currently is"

"for people just navigating visually, if you are trying to fill out a form like this, it's pretty easy to just look at it and determine what is actually happening"

CSS shouldn't carry meaning (7m50s)

Don't use CSS to convey state — a red border alone is invisible to screen readers. Don't rely on the content property either; support for generated content being exposed to assistive tech is a patchwork across browser/AT combinations.

"we shouldn't be using CSS to convey any of that meaning or content that HTML is actually supposed to be used for"

"if the only way you're gonna convey [an error] is through styling a border, then that's something that just wouldn't be able to be communicated to users of assistive technologies"

"you shouldn't use that CSS-generated content to create or alter any important information on the page"

How to hide things without hiding them from screen readers (9m26s)

The five common "hide" techniques look identical to sighted users but behave very differently for assistive technology. display: none removes the element from the accessibility tree. visibility: hidden is poorly named — it keeps the element's box but makes it invisible and unread. For tooltips and similar UI that needs to be readable, position the element off-screen with position: absolute rather than removing it.

"visibility hidden... it's not really just about visibility — it operates more like an invisibility cloak than anything else"

"in most cases where you want something to be hidden but still accessible to screen readers, just using position absolute and essentially moving it off the page is the best option"

"if you have a good use case [for visibility: hidden], you can try and find me and convince me"

Source order, focus styles, and default browser CSS (12m02s)

Flexbox and Grid let you reorder visually without touching the DOM — with great power comes great responsibility (Rachel Andrew). Default browser CSS is standing on the shoulders of giants — your custom CSS should improve on it, not break it. Focus styles in particular: if you remove the outline, you must replace it, and :focus-visible is the modern lever for "only when the user navigates by keyboard".

"with that great power comes a lot of great responsibility... that also enables us to do crazy things in terms of just defining our DOM in whatever way, and then quote-unquote fixing everything with our CSS"

"anything I write should be done understanding why the default was done the way it is done"

"if we're going to remove the focus outlines for example, we should replace it with something else — not just remove it entirely"

CSS that genuinely improves accessibility (16m42s)

Default CSS is one-size-fits-all; your CSS can specialise. Examples: tighten line-height and max-width on text-heavy pages, add skip-links for keyboard users, use @supports to provide a graceful fallback for older browsers, and respond to user preferences like prefers-reduced-motion, prefers-color-scheme, prefers-contrast, prefers-reduced-data.

"the default browser styles are sort of like a base and are meant to be as accessible to as many different websites as possible — but that basically means they're not going to be necessarily optimised for any particular website"

"if a user prefers reduced motion, then we can have something a bit more scaled back or removed entirely"

"the core of this again is just about giving users as much control over their experience as possible"

JavaScript should enhance, not replace HTML (22m26s)

JavaScript's job is to make the page more interactive, not to recreate functionality HTML already provides. A <button> is focusable, keyboard-activatable, accessible-named, and state-aware for free. Replacing it with a <div> plus tabindex, role, key handlers and JavaScript state-management is just working against yourself. And every JS enhancement should use preventDefault() rather than replace the default flow — that way, when JS fails, the HTML still works.

"JavaScript should ultimately be used as something to enhance the website — like the icing on the cake"

"at the end of doing all of that you're just like, okay, why? Because I'm just working against myself"

"using event.preventDefault puts you in the right state of mind, because you're like, okay, there's actually a default experience that I'm going to prevent"

When JS is the right answer (30m36s)

JavaScript isn't the enemy — only 0.07% of screen-reader users disable it. But over 50% of Sudan's mobile browsing population is on Opera Mini, which strips most JS. Use JS where it materially improves the experience (Google's did you mean…, accessible video players that fix the native <video> element's keyboard problems, brand-new components like carousels that HTML doesn't natively provide), and skip it where HTML already has the user covered.

"in Sudan over 50% of mobile browsing population is with Opera Mini, which severely reduces or just completely eliminates all JavaScript"

"by adding JavaScript you're drastically changing what the page size is going to be"

"some HTML elements are not actually accessible enough yet — so much so that we might actually need JavaScript in order to correct them"

Reframe: don't make it inaccessible in the first place (35m45s)

The closing reframe, borrowed from George Kemp: when someone says make the website accessible, don't add an accessibility task to the backlog — just don't make it inaccessible in the first place. The default is accessible. Every CSS rule and JS handler you add is a choice not to break that default.

"the default is that it is accessible"

"if someone says 'make a website accessible', you should instead say 'actually I'm not going to make it inaccessible in the first place'"

"we shouldn't be using JavaScript for what HTML's job is, or what we can already do with HTML"