Category: dai11y

Your daily frequent11y newsletter, brought to you by @ChrisBAshton:

The Monarch could be the next big thing in Braille

A collaboration project between HumanWare and the American Printing House for the Blind (APH) has resulted in the Monarch: a “multipurpose” Braille device.

Refreshable Braille displays have existed for years, but have been expensive, slow to refresh, and fragile. A new “braille pin mechanism” created by startup Dot has been incorporated into the design: these pins are individually replaceable and are much faster to raise.

APH partnered with over 30 international organisations to create a new electronic braille standard, called eBRF. “This will provide additional functionality to Monarch users including the ability to jump page to page (with page numbers matching the print book pages numbers), and the ability for tactile graphics directly into the book file, allowing the text and graphics to display seamlessly on the page.”

The author notes that the graphical capability is “a serious leap forward”. It will now be possible for braille readers to pull up a visual of a graph, animal, letter or number shape, allowing the consumption of simple graphics. From APH.org:

The Monarch is approximately 4.5 pounds and the size of a 15-inch gaming laptop. The device features an 8-dot braille keyboard, zoom in/out buttons, direction pads, up/down arrow buttons, and a 10 line by 32 cell refreshable braille display, which is capable of rendering multiple lines of braille and tactile graphics with equidistant pins. This technology will bridge the educational gap for students along with the development of a new dynamic file type that will bring braille and graphics together in a navigable file.

The Monarch is not currently available to purchase. You can sign up to product updates on the website above.

---

Prefer longer newsletters? You can subscribe to week11y, fortnight11y or even 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.

Your daily frequent11y newsletter, brought to you by @ChrisBAshton:

Flexbox and the Screen Reader Experience

A Webaim article that reminds us that whilst CSS flexbox can be used to change the visual order of content, it often has no bearing on how the content is consumed by a screen reader. This can lead to major accessibility issues if the intended reading order differs from the order in which it appears in the DOM.

The takeaway is to always structure information in the correct order in the DOM, then ensure that visual presentations (at all widths) convey that order. The author doesn’t want us to leave with the feeling that flexbox is “dangerous”, but that it is powerful and that screen reader testing is essential.

---

Prefer longer newsletters? You can subscribe to week11y, fortnight11y or even 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.

Your daily frequent11y newsletter, brought to you by @ChrisBAshton:

Brief Note on Buttons, Enter, and Space

An interesting article by Adrian Roselli, sharing something I didn’t know:

A native <button> fires on key down when that key is Enter. If you hold down the Enter key, it continues to fire for as long you hold Enter (or something crashes).

A native <button> fires on key up when that key is Space. If you do not release the Space, and also press Tab to move away from the control, the control will not fire.

These can blow up once a screen reader is in play. If you run Narrator/Edge, pressing Space is the same as pressing Enter, but holding either down does not repeatedly fire the event. NVDA/Firefox and JAWS/Chrome treat Space as Enter — fires on key down and holding it down continues to fire. The Windows screen readers all intercept the event, so you cannot listen for which key was pressed in your page. VoiceOver/Safari/macOS behaves as if VO was not running, and (in my script) the keyboard events are captured.

…and that’s pretty much the whole article! There’s also an interactive example so you can try it out for yourself. The TLDR is to be careful when trying to re-implement native browser behaviour in your custom components, and consider the nuance of the different keys, to support your powerusers.

---

Prefer longer newsletters? You can subscribe to week11y, fortnight11y or even 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.

Your daily frequent11y newsletter, brought to you by @ChrisBAshton:

Accessible front-end components: claims vs reality

Hidde de Vries shares his tips for finding accessible components, warning that many components that claim to be “accessible” actually aren’t. Hidde’s checklist:

• How did they test? A component’s website should ideally explain how a component was tested, e.g. perhaps only automated tests have been run and you should do some further testing before choosing it. Try to find specifics around exactly what version of WCAG they claim to be valid against, for example.
• Who did they test with? Accessibility isn’t just about technology, it’s about making sure a pattern works for people with disabilities. Did the developers specifically include people with disabilities, in their testing?
• Are they open about the pros and cons of their approach? It’s a good sign if the developer is open about this, as many components aren’t one-size-fits-all.
• Who created them? Hidde puts extra trust in components developed by organisations that work in accessibility or work for the public good.
• Look at GitHub issues – their presence could be a warning sign.
• Find out about commitment – are they proactive or reactive in their component’s development?

---

Prefer longer newsletters? You can subscribe to week11y, fortnight11y or even 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.

Your daily frequent11y newsletter, brought to you by @ChrisBAshton:

Face-off: Should kit colours be catered to colour-blind fans?

Anyone who’s ever played FIFA on a game console will at some point have ended up playing a game where both sides have really similar looking kits. It becomes difficult to know who you can pass to, and makes the game less enjoyable.

This is an issue faced by the large portion of sports viewers who are colour blind, and consequently, the 2027 Rugby World Cup will be the first that bans red-green kit clashes.

This article from RugbyWorld.com shares an opinion-piece from two enthusiasts. The first is in favour of the move, for obvious reasons. The latter is against it, favouring the idea of a ‘home kit’ and an ‘alternative white kit’, which would solve the problem in a different way. He argues that “turning out in the colour of your nation matters”.

I think the announcement is a positive move for accessibility, but it’s interesting to think about the different ways the issue can be tackled.

---

Prefer longer newsletters? You can subscribe to week11y, fortnight11y or even 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.

Your daily frequent11y newsletter, brought to you by @ChrisBAshton:

The Surprising Truth About Pixels and Accessibility

Josh Comeau dispels the myths around using px, rem and em in your designs. He introduces these with no assumed knowledge, gradually explaining when to use each one, using inline interactive examples to aid learning. It’s really worth checking out.

My takeaways:

1. A reminder that px doesn’t actually map to hardware pixels, but it’s the most concrete measurement we have.
2. There are two main ways a user can make the text on their screen bigger: “zooming” (⌘ + + on MacOS, ctrl + + on Windows/Linux), or “font scaling” (changing the browser’s default font size).
3. When deciding whether to use pixels or rems, ask “Should this value scale up as the user increases their browser’s default font size?” If yes, use rem, if no, use px. So you’d use rem for text, but you might use px for borders or padding.
4. Josh recommends using rem over em due to em‘s compounding issues (making it hard to predict what size an element actually ends up being). An exception is for the margins of headings and paragraphs, for which Josh uses em.

It gets more complicated: should you use px or rem in your media queries? The answer is rem. If a user has increased their default font size, the available space is reduced, so they’re more likely to need your ‘mobile’ view. Using a rem-based media query such as @media (min-width: 50rem) means a user who increases their default text size will need a bigger screen to get the non-mobile styles. (If a user sets their default text size to 32px, this is “double the standard text size” and means that “50rem will now be equal to 1600px instead of 800px”).

Josh goes into more examples. Be careful when using rem to define button sizes, as declaring something like width: 15rem could mean the button becomes too large for its container. You can combine this with max-width: 100% to prevent the overspill. Similarly, use min-height as opposed to height.

Josh ends the article by discussing the numerous ways you can manage your rem size to px conversions, e.g. through defining a 62.5% base font size, using calc, or leveraging CSS variables.

---

Prefer longer newsletters? You can subscribe to week11y, fortnight11y or even 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.

After a few weeks off, the frequent11y newsletter has returned!

A Practical Approach to Automated Accessibility

Mark Steadman writes a mini series on automated accessibility. In this introductory article, Mark introduces his three-step plan for introducing automated accessibility checks into your pipeline:

1. Phase 1: Linting
   • Linting is a quick and easy step for catching issues by statically analysing source code.
   • In his subsequent article, Mark recommends axe Accessibility Linter that enforces around 30 accessibility rules. He also recommends webhint and HTML Validate.
   • Mark claims that linting is expected to catch around 20-25% of accessibility issues: basic ones such as images missing the alt attribute.
2. Phase 2: Automated Accessibility Libraries
   • You can add a library such as axe-core or pa11y into your pipeline, configuring it with a list of routes to visit. The library will perform some general accessibility checks on your application at runtime, as opposed to just looking at the source code. This can catch contextual issues such as a piece of text having poor colour contrast against its background.
   • In Mark’s accompanying article, Automated Accessibility Part 2: Mobile Web Testing, Mark elaborates on how to configure these libraries to run against responsive views of your application. For example, you can run pa11y against the ‘mobile’ view of your application by pairing it with a browser emulator tool such as Cypress.
3. Phase 3: Accessibility Regression
   • Mark’s final phase of automation is to create “regression tests”. These are specific, accessibility-focused unit tests, written in code. For example, you can write a test that checks that aria-expanded is being properly set every time a user clicks on an expand/collapse section.
   • Mark builds on this in his article, Automated Accessibility Part 3: Regression Tests, which builds on the Cypress automation of the previous article and shows example code for interacting with the page and asserting conditions.

There are a lot of different testing approaches and tools out there, so having a three phase plan for testing is a useful way to make the process less daunting.

---

Prefer longer newsletters? You can subscribe to week11y, fortnight11y or even 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.

Your daily frequent11y newsletter, brought to you by @ChrisBAshton:

Progress Over Perfection: The Better Way for Communication and Accessibility Advocacy

This article by Meryl Evans really resonates with me.

Accessibility is big and daunting. It needs to be considered in every facet of an organisation: “HR needs to ensure the hiring and employee benefits processes are accessible. Procurement needs to ensure the company buys accessible products and services”. People will inevitably make mistakes – even Accessibility Advocates!

Progress isn’t always a straight line – sometimes it will go backwards. They key is to get started and keep moving. You can start with something as simple as an accessibility statement on your website, giving people an avenue for reporting accessibility issues. Don’t spend years trying to perfect everything behind the scenes before launching your 100% accessible product – be iterative.

One exception that muddies the rule a bit is the use of overlays. Whilst these have the feel of “progress over perfection”, they make your product less accessible, not more so. Better to ask companies to remove these overlays, through educating rather than berating. Meryl follows these four steps:

1. Show gratitude for what they do right.
2. Provide the suggestion.
3. Explain the reason for the suggestion.
4. End on a high note or with a thank you.

“Progress over perfection”, and being kind, gets results.

---

Prefer longer newsletters? You can subscribe to week11y, fortnight11y or even 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.

Your daily frequent11y newsletter, brought to you by @ChrisBAshton:

10 Ways Designers and Researchers Can Meaningfully Engage With Disabled People in 2023

A thought-provoking article with some really useful takeaways.

Some tips are practical/logistical:

• Bring disabled people into your process “from the very beginning”, before you’ve locked in your design problem or research questions. Doing so allows you to make the best use of these community members, allowing them to lend their expertise and be true collaborators, rather than just ‘rubber-stamping’ your design.
• Offer remote and asynchronous participation. “Can you offer to do interviews over instant messaging or email? Can you run a focus group on Slack or Teams chat? Can you provide workshop materials and interview questions in advance so that your participants have extra time for cognitive processing?”
• Consider what changes you can make to properly reward your participants.

Others are a change in mindset:

• Reframe your design thinking: instead of “designing for” trust, you should “design against” abuse and exploitation. “Designing against” helps to avoid feature creep and lets you focus on just “the structural factors that are really, materially shaping those problems”.
• “Be Deliberate About How You Categorize / Segment Disability”, i.e. instead of asking “what kind of disability do you have?”, ask “which of these things are difficult or inaccessible for you?”. Understand that some people don’t yet have a medical diagnosis for their disability. Ask about barriers and difficulties rather than disabilities.
• Related: how should you hire disabled people in the first place? Traditional networking and going through large-scale disability charities is not inclusive, says the author. Instead, they propose hiring “a couple of disabled people as outreach coordinators”: people who are “politically engaged enough to be connected to small grassroots organizations, to be aware of current and ongoing issues within disability communities and how those need to be reflected in design research questions and recruitment profiles for research participants”.
• There are also sections in the article about “thinking about power”, stopping “ignoring invisibilized disability”, and “thinking about accessibility in terms of time and energy, not just space and matter”.

---

Prefer longer newsletters? You can subscribe to week11y, fortnight11y or even 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.

It’s been a little while since my last dai11y, partly because Mailchimp have recently upped their prices, meaning I’m no longer within the free tier. I’ve been procrastinating moving to a different provider, but will give that some more thought. I’ll also be on annual leave for a while now, so you won’t hear much more from me until June.

With that out of the way, onto today’s issue!

Washington Post Design System

The world is divided into people who like perusing design systems, and those who don’t. I actually fall into the latter category – I find that these systems require a lot of time sunk into them, and often just reinvent the wheel – but even so, here’s the Washington Post version.

It’s worth a quick click through to see the accessibility checklist, the screen reader shortcuts, and the pretty comprehensive overview of alt text (from a technical implementation and content writing perspective).

---

Prefer longer newsletters? You can subscribe to week11y, fortnight11y or even 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.