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.
Lefty dentists and inclusive design
An article about the barriers faced by left-handed dentists, in what the article author, Robert Stribley, calls “a failure of inclusive design”. Robert’s dentist immediately “became a better dentist” after graduating dental school, as they were able to set up their working environment to best suit them.
Barriers occur in everyday situations:
The pen you have to sign things with at the bank is often positioned for right-handed people. The machines for swiping your subway card here in New York are exclusively positioned for right-handed people. And scissors? Ask left-handed people about scissors. When you’re left-handed, you realize how insensible it is for scissors to be designed exclusively for right-handed people. In fact, when I was living in Pusan, Korea in the mid-90s, I found that ambidextrous scissors were available everywhere, so I bought two pairs and still use them to this day.
Going back a few decades, children were literally punished for being left-handed, and were forced to write right-handed. Between the early 1900’s and 1960’s, the rate of left-handedness appeared to “increase” as it gradually became more accepted – but the proportion has almost certainly been constant throughout, it’s just that a large number of left-handed people had to suppress their instincts and learn to live right-handed.
Robert compares this to “the idea that transgender people have suddenly been materializing in our society, due to either being transgender becoming trendy or, worse, because (some critics posit) children being “groomed” by adults to be trans. Of course, the simpler answer is simply that transgender people are rising in numbers because they’re no longer being stigmatized to the degree that they once were”.
Robert, a creative director & “UXer”, amongst other things, concludes with this:
As we come to understand the diversity of our shared human experience then, we’re increasingly exposed to opportunities to develop more inclusive design practices. This applies across the whole spectrum of design, including the design of physical products and digital experiences.
There are both noble and practical reasons to practice inclusive design. And no good reasons not to.
When to use target=”_blank”
An old CSS-Tricks article by Chris Coyier, worth reading as a refresher.
The default value for the target attribute, if unspecified, is “_self”, meaning links open within the same window. Using “_blank” forces links to open in a new window or tab. Users can opt in to opening in new tabs by using CMD + Click when opening links, so they have the choice without being forced into any one decision.
Chris points out some bad reasons that have been used in the past to justify forcing links to open in new tabs:
- For branding, metrics and engagement. Opening new tabs means people still have your website on their original tab, keeping them on your site.
- Because internal and external links are different. Quite a few sites only open ‘external’ in a new tab.
- Because the link is to a PDF. Users can still use the back button, so why a new tab? (PS if you’re trying to make it easier to download, use a
downloadattribute on the link instead). - Because your client wants it that way. Chris suggests educating them about not frustrating their users.
- Because it’s an infinite scroll page (to avoid the issue of handling ‘back’ behaviour after a long scroll).
Chris then lists some good reasons for opening in new tabs:
- Because there is user-initiated media playing.
- Because the user is working on something that would be lost if the current page changed.
- Because there is a technologically obscure reason. Chris cites “building an email where people in Outlook Kangaroo 2009 Enterprise Edition need to open it but links need to have target=”blank” on them otherwise they open in the sidebar viewing panel”…!
Last but not least, don’t forget to add the rel="noopener" attribute when opening in new tabs, for security reasons. This is less relevant now we’re approaching 2023, but the article hasn’t been updated to remove that advice yet, so I’d err on the side of caution and keep doing it.
Linux Accessibility: an unmaintained Mess
Devin Prater shares his experiences of trying to use Linux as a blind person.
He reminisces about the days of Gnome 2 on Vinux, which was “accessible and easy to use” when used with Orca, the Linux GUI screen reader. Around 2015, Sonar came along, based on Antergos (Arch Linux). Both projects “are no more”, due to infighting when the two planned to merge.
With Vinux and Sonar abandoned, many blind Linux users moved to mainstream distributions, which vary in their accessibility. Devin shares tale after tale of the barriers he faces and overcomes, only to be faced with another barrier. I won’t reproduce it all here, but safe to say that even when doing everything right, Devin would need to enable settings on a per-app basis, find things were incompatible and that key processes would crash. If someone as technically competent as Devin faces these issues, other users have no hope.
Devin ends with a call to action, for the open source community to care enough about accessibility to “clean up the mess they started”. He was forced to reinstall Windows, and highlights how not being able to use Linux is impacting his ability to get a skilled, well-paid job. Devin points out that the blind community are the very people that stand to benefit most from gaining system administrator skills and so on, if the accessibility barriers can be overcome.
Setting up an Accessibility Book Club
Beverley Newing, Accessibility Lead at the Ministry of Justice Digital and Technology, describes how they set up an ‘Accessibility Book Club’.
The club helped Beverley to create accountability, to ensure they were setting aside time to read and hear about the experiences of disabled people. The club can read books, or watch films/documentaries/TV series, but the item has to be about (or written by) someone disabled, or be on the topic of disability.
Beverley suggests using an online location as a meeting point, e.g. Google Meet. Create a calendar placeholder and a series of questions to serve as discussion prompts. Finally, create a Slack poll (or similar) so that the next media item can be voted upon.
The author has open-sourced a “collection of resources to help run an accessibility book club”. The linked app is down at time of writing, but you can access the resources on GitHub.
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.
