Your fortnightly frequent11y newsletter, brought to you by @ChrisBAshton:
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”.
Stephanie Eckles shares 4 quick checks you should make before pushing to production.
- 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!
- 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.
- All focusable elements must have visible styles.
- 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.
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.
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.
A helpful utility for generating accessible color combinations. View the project on GitHub or follow it on Twitter.
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”.
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.