month11y issue 34

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…

What Does X% of Issues Mean?

Adrian Roselli ponders what tools mean when they claim to find up to X% of issues. What do “issues” mean in this context?

He ran a Twitter poll with a few options; most people interpreted “issues” to mean ‘issues validating against the 78 Success Criteria from WCAG 2.1’. But this was closely followed by people who thought it meant “against the tool’s own list of items”, i.e. tests unique to the tool. Finally, a small minority thought it might be against Techniques for WCAG 2.1, which “provides 90 different ways of failing assorted Success Criteria”.

Not a hugely informative post, but an interesting thought piece. Adrian recommends asking vendors to clarify exactly what they mean by “issues”.


4 Required Tests Before Shipping New Features

Stephanie Eckles shares 4 quick checks you should make before pushing to production.

  1. Almost 85% of homepages have text contrast issues – so check your colour contrast. Stephanie lists some automated tools that can detect these issues.
    • Use ButtonBuddy to choose accessible colours for your buttons and their focus states. For the text, background colour, and transition between focus states, there are five con trast considerations you’ll need to make!
  2. Next consider keyboard interaction – here’s a handy set of rules, which I’ve copied directly from the article:
    • If it opens something, it may need to close with Escape.
    • If it’s scrollable, it needs to respond to Up/Down arrow keys.
    • If it’s a group of related options (like autocomplete or tabs), it may need to respond to Up/Down or Left/Right arrow keys (search phrase: roving tabindex).
    • If it opens a dialog/modal, it needs to prevent tab access with elements outside of that experience (search phrases: “trapping focus” and “inert”).
    • If it’s interactive at all, it needs to be able to gain keyboard focus, and that focus needs to have a visible style.
    • If a sighted mouse user can explore and make independent selections (like in an autocomplete), a keyboard user needs to be able to as well. This likely means allowing a combination of tab, arrow keys, and Enter to explore and then make a selection.
    • If a :hover triggers content, then so should :focus (ex. menus). You will also need a way to close this content, whether that’s a tap/click outside or Escape key, and ensure that the method you choose is also accessible for touchscreen users.
  3. All focusable elements must have visible styles.
  4. WCAG SC 1.4.10 Reflow stipulates that your design should be able to accommodate a zoom of up to 400% on desktop. Watch out for sticky navigation, ‘contained scroll’ areas becoming cut-off, or overflows that cut off content.

Why ‘dark mode’ causes more accessibility issues than it solves

H Locke, a UX designer, talks about astigmatism, which affects around 47% of the UK population. Actually Locke points out it affects most of the population, but the 47% figure is those that require corrective treatment, such as lenses or glasses.

The condition affects the shape of the eye, making it more ‘rugby ball’ shaped than football shaped. This leads to light being focused at more than one place in the eye, and can cause blurred vision, headaches and eye strain.

Locke says that the ‘dark mode’ on certain websites can cause an effect called ‘halation’, for those with astigmatism. There’s a mocked up screenshot in the article, demonstrating the effect, but it essentially makes the area surrounding highlights blurry. In dark mode, there are a lot of highlights (e.g. white images are more pronounced), so the text around the images becomes blurred.

Dark mode advocates often cite it as an accessibility feature – and it is an improvement for some people – but Locke reminds us of the importance of making such modes optional.


Why you should never use px to set font-size in CSS

Josh Collinsworth dispels the myth that it doesn’t matter whether you use px, em or rem for your font sizes.

Whilst px stands for “pixels”, it no longer translates into physical pixels on the screen, as browsers scale up pixels on higher resolution screens. “Pixels on the iPhone 14 Pro are so microscopic that 16px, in literal device pixels, would be about the size of printed type at 2pt font size”.

em once referred to the physical size of an “m” character, but now refers to “current font size”. rem stands for “root em“, and refers to the root font size. By default, 1 em and 1 rem are equal to 16px (the default font size of most browsers). But whilst 1 rem generally remains at a constant 16px, the ‘pixel size’ of 1 em changes based on its context.

With the CSS .container { font-size: 200% } and .container p { font-size: 1em }, the 1em here will actually render as a 32px size, not 16px.

Understanding how this works is the key to unlocking why defining font sizes in px is a bad idea. em and rem work with the user’s font size – the user can change the browser’s default font size and everything will scale accordingly. Defining font sizes in px overrides the user’s choices.

The misconception most likely comes from this: developers zooming in to test their web page, and noting that fonts seem to scale up and down irrespective of the unit type used. However, not everything scales in the same way.

If you set CSS of p { border-bottom: 2px solid black; margin-bottom: 20px }, and then change the default browser font size to 64px, you’ll see some large text, but the surrounding spacing and borders don’t scale with it. Setting these values with em or rem would mean they would scale with the text. Zooming in and out does scale the border and spacing, but it’s so undersized compared to the root font size that it looks terrible. See screenshots in the article.

For similar reasons, it’s important not to use px in your media queries. If the user overrides their root font size, you may find that your breakpoint does not trigger at the width that you expect it to.

Josh summarises with a recommendation to use rem by default, only using a smattering of em where it’s important to make something relative to the size of its container, and only using px for certain aesthetic elements that you would not want to scale with the user’s font size.


https://randoma11y.com/

A helpful utility for generating accessible color combinations. View the project on GitHub or follow it on Twitter.


Why we need CSS Speech

LĂ©onie Watson describes how all modern browsers allow you to “listen to content”, either natively or through some plugin/extension, and how developers currently have very little control over how content gets read. “In the same way an organisation chooses a logo… it stands to reason that they may also [wish to] choose a particular voice that represents their brand”.

Speech Synthesis Markup Language (SSML) is intended for this purpose, but involves mixing in special markup inside your HTML. LĂ©onie argues that this returns us to the bad old days of having to mix styling into our HTML, before CSS allowed us to separate content from its presentation. (By the way, SSML isn’t supported in any browsers yet).

LĂ©onie points us to the CSS Speech Module. It is a W3C Candidate Recommendation, thus has not yet achieved the status of W3C Recommendation. In short, it proposes a set of CSS properties to let authors define the aural presentation of content, whether read out by someone’s screen reader, a browser’s read-aloud capability, or a platform Text To Speech (TTS).

The speak: property would act like the display: property; the latter determines whether an element is visible, and the former would determine whether the element should be spoken. These would be linked; if an element is set to display: none, for example, then the element would also not be spoken, unless an override is provided. Other properties proposed include voice-family, voice-pitch, voice-rate and voice-volume.

LĂ©onie is hoping to edit the CSS Speech module, stripping it down to its bare minimum, as the current proposal is “too big, too wordy, and has too many features”.


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-motion
  • prefers-reduced-transparency
  • forced-colors
  • prefers-color-scheme
  • prefers-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 download attribute 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.


Whew, that was a long newsletter! Did you know that you can subscribe to smaller, more frequent updates? The dai11y, week11y and fortnight11y newsletters get exactly the same content. The choice is entirely up to you! Curated with ♄ by developer @ChrisBAshton.

Loading...