Why <details> is Not an Accordion

Dave Rupert on why that (wonderful) way of Using the <details> element to create modals and menus is not good for semantics. Because <summary> has role=”button”, it eats the semantic content of elements inside it. So that big <h1> inside of your <summary> becomes just another piece of text, sans semantics. I especially like this […]

Making a Better Custom Select Element

24ways – the advent calendar for web geeks – is back! First post is “Making a Better Custom Select Element” in which Julie Grundy tries to create an accessible Custom Select Element: Sometimes, I can’t recommend the select input. We want a way for someone to choose an item from a list of options, but […]

Indicating focus to improve accessibility

Great article by Hidde. It totally rhymes with my Building Better Forms™ by not taking away affordances post. 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. Indicating focus […]

Building Better Forms™ by not taking away affordances

Don’t fiddle too much with your forms‘ look and feel. A small innocent-looking piece of CSS, even when combined with semantically correct HTML, could leave you with a degraded User Experience and make your forms less Accessible. Yesterday I went to see Girl at Kinepolis. Whilst ordering tickets I ran into an issue though: after […]

Hiding inline SVG icons from screen readers

Roger Johansson: SVG files may contain a title element which may or may not get announced by screen readers (depending on SVG embedding technique, browser name and version, and screen reader name and version). So far I haven’t run into a situation where I want any other behaviour than screen readers completely ignoring icons (since […]