Archive

It's not easy to build very good UI components. A global effort to try and find the best qualities of components would be a great opportunity to improve components everywhere.

Notes from discussions on 11.8, the part of EN 301 549 that is about authoring tools.

What does “built in accessibility” actually mean for browsers that support popover?

Are LLMs helpful tools to assist with making accessible front-end components? Let's find out.

Common questions I hear about web accesssibility with short, low on nuance answers.

When someone called out lack of accessibility, they got ableist responses. This post has a collection of those responses and an explanation of why they're problematic.

To improve accessibility of the web as it is today, I feel we dearly need accessibility guidance that is holistic, well tested and easy to use.

I wondered if Ctrl/⌘ + F in a browser can be a way to meet ATAG A.3.5.1

What is the ACT Rules CG and why is it great they published implementations?

Interop 2022 makes a great impact for web developers, should something like an accessibility-specific Interop exist?

Six tips on coming up with accessible names

WCAG 2.2 has officially reached “Candidate recommendation” status, meaning it is pretty close to becoming an official standard. What's new?

Keyboard shortcuts can make your website or app much more keyboard friendly. But they need modifier keys.

On why :focus-visible is more than a way to target keyboard users only.

Is the accessibiliy of a website a binary thing? It depends!

I've worked in web accessibility in various positions, this post is about how the accessibility-specialised developer's position can be difficult.

As a follow up to my previous post about common accessibility issues, I have written out five more issues that you could fix today.

Tips based on WebAIM’s “Million” survey.

A quick response to Dave Rupert’s post on HTML and ARIA.

Thoughts about auto-adding lang attributes.

Many ask ‘How many users with disabilities use our site?’ We probably don’t need to know, if we need to decide whether to improve web accessibility on our sites.

I’m a little torn on whether to see prefers-reduced-motion as a sufficient way to meet 2.2.2 Pause, Stop, Hide. My thoughts.

Many use WCAG as a baseline to ensure web accessibility. In this post, I look at doing less and doing more than the standard.

In which I argue app stores need fields for accessibility meta information.

In which I go into the difference between normative and non-normative in WCAG.

Not all ‘accessible components’ are created equal. Find out which will work best for our end users with this checklist.

Web accessibility becomes easier and cheaper, when you address it earlier.

Why having no content between headings can be problematic.

A written version of my lighting talk “Breaking barriers with your CMS”.

Proposals for the Accessibility Object Model include a new way to convey semantics: without markup, directly in JavaScript. This post looks at the proposals and their current status.

It’s a common, but fairly easy-to-fix accessibility issue: lack of indicating focus. In this post I will explain what we mean by focus and show you how focus outlines make your site easier to use.

Some thoughts on seeing declarative component frameworks as a way to make the web more accessible, not less.

Why and how the right HTML elements can improve the user experience of people that use assistive technologies.

On lang, hreflang and BCP47.

Heading structures give screenreader users and others a table of contents for our sites. By being conscious of that, we can make better choices about heading levels and their contents.

According to WCAG 2, criterion 2.4.2, web pages should have titles. How to go about this in a single page world?

With display: contents, we can have more accessible markup for our CSS Grids. One caveat: supporting browsers currently break this.

Alternative text is a great opportunity to make the non-text parts of the web accessible. However, look out for redundancy, and only add it when it conveys something that isn’t already there.

All interactive elements should have accessible names and can have descriptions. In this post I explain labelling with native HTML and ARIA attributes and discuss how to future-proof your labelling.

A post about how the hidden attribute works, how it differs from [aria-hidden] and how it relates to just hiding with CSS.

On how to help users see which fields have errors, what’s wrong with them and how to fix it.

About a workflow for improving the accessibility of conference videos