We’re fast approaching Christmas, and I have a gift for you. You can shape the future direction of this newsletter by filling in my survey! It would really help me to understand what you like or don’t like, which subjects you’d like to read more about, all that lovely stuff. All I Want for Christmas is You(r) thoughts on my newsletter – please fill it in! 🎄 Now on with the show…
HTMHell Advent Calendar 2022
Manuel Matuzović’s famous “HTMHell” site cites lots of examples of bad HTML practices, copied from real websites. See “button disguised as a link“.
Last year, Manuel created an ‘advent calendar’ of links to other sites, linking to articles about HTML.
This year, Manuel has enlisted the help of 24 authors from all over the world, to write and publish articles specifically for Manuel’s calendar.
Visit the calendar link above to see the articles published so far, or follow along on Twitter.
Should browsers offer site-specific user preference controls? (yes!)
Stefan Judis dreams about what could be made possible in browsers in this short opinion-piece.
Users can set an OS-level or browser-level preference for light or dark mode, but there’s currently little support for configuring this on a per-site basis. What if you simply prefer a particular mode on a specific site, even if it goes against your global settings?
Stefan highlights Safari’s website-specific controls menu, which can only be accessed after enabling them via toolbar settings. Here, users can set preferences on page zoom, autoplay, and permissions including location and camera access, on a per-site basis. Stefan feels other preference should be configurable here too.
Stefan would like to see ‘preference queries’ not only easily configurable globally, but easily overrideable on a per-site basis. These include:
prefers-reduced-motionprefers-reduced-transparencyforced-colorsprefers-color-schemeprefers-reduced-data
Hopefully one brave browser will lead the way and this could become a reality one day.
A Guide To Keyboard Accessibility: HTML And CSS (Part 1)
This is a comprehensive run-through of a lot of the stuff you may already know: how different tabindex values affect keyboard behaviour, the new(ish) :focus-within CSS selector to be able to apply focus styles on a container element, the new (and not ready to use yet) inert attribute that promises to make modal dialogs much easier to implement, and so on.
There are some nuggets of handy tips and links to resources that were new to me though. Did you know that Firefox allows you to tab to any area that is scrollable (i.e. even if it isn’t a form control or link)?
There’s a reminder to not use outline: none in your CSS (to eliminate the element’s outline), as it is used by Windows High Contrast Mode. And, despite showing an example that demonstrates otherwise, we’re told to avoid wrapping <input> with <label> because it doesn’t work well with Dragon speech recognition software.
We’re warned against the use of display: contents, which effectively makes the element’s children direct descendents of the element’s container (i.e. the childrens’ grandparent), but “without losing semantics”. It’s an interesting concept, but one that is quite buggy, and best avoided. There’s also a section about CSS grid and flexbox, and the care needed to ensure that tabbing continues to be in a predictable order.
I liked the section about ‘skip links’ towards the end of the article. It reminds us that we can provide multiple skip links at the top of the page, e.g. to skip to main content, or to skip to a list of all articles. We can also apply skip links within content, e.g. if there is an embedded map in the page and it has lots of focussable elements, you may want to give the keyboard user an option of skipping over it.
Further reading: MDN web docs page demonstrating lots of different input types, so that you can try interacting with each one of them using your keyboard.
A Guide To Keyboard Accessibility: JavaScript (Part 2)
In this second part of a two-part series, we move away from HTML and CSS and take a closer look at JavaScript.
The click event listener listens for a mouse click, but is also triggered by the Enter key (on buttons and links) and the Space key on buttons only. For other keys, you’d need to use the keydown event. This is often used for things like enabling the Esc key to close a modal. You can use keycode.info to find out which key code corresponds to the key you’re listening for.
Another important event is blur, which indicates that the element has lost focus. Combined with the keydown event, you can use this to add and remove a class on the given element, so that the state is wiped clean on each interaction and you can (for example) continually open and close a modal.
Next, we learn about the focus() method, which allows you to bring the keyboard focus to a particular element. It can be used with the preventScroll argument to ensure the browser doesn’t scroll as part of the interaction. There’s also a new focusVisible argument, which would prevent the focussed element from displaying its focus styling, but this currently only works in Firefox.
There’s a section on “roving tabindex“ which looks interesting – check out the demo. Sadly, the role="tab" and role="tabpanel" attributes are left unexplained, but there’s lots of detail about the actual JavaScript implementation.
The inert attribute mentioned in dai11y 15/12/2022 (intended for things like modals) gets a second showing here: the author talks us through how we should implement a modal at the moment (with inert not yet supported). We give it a role="dialog" and aria-modal="true" for screen reader, and a tabindex="-1" to make it programmatically focussable. Then, we create a function to open the modal, but need to keep track of which element opened it, as we’ll need to return focus to that element when closing the modal. The code looks something like:
let focusedElementBeforeModal;
const modal = document.querySelector("[role='dialog']");
const openModal = () => {
focusedElementBeforeModal = document.activeElement;
modal.hidden = false;
modal.focus();
};There’s some more detail about modals / focus traps and how to use the new inert attribute, towards the end of the article.
Did you know that you can subscribe to dai11y, week11y, fortnight11y or month11y updates! Every newsletter gets the same content; it is your choice to have short, regular emails or longer, less frequent ones. Curated with ♥ by developer @ChrisBAshton.
