This free day-long online event all about accessibility and inclusive design is happening right now. You can join live, or catch up on the talks that have already happened, like the excellent talks from Russ Weakly and Manuel Matuzović.
Vitaly provides some sensible rebuttals.
It looks like it will be a great tool for prototyping. A tool to help developers that don’t have experience with CSS and layout to have a starting point. As someone who spent some time building smoke and mirrors prototypes for UX research, I welcome tools like this.
What concerns me is the assertion that this is production-grade code when it simply is not.
An impressive piece of internationlisation and inclusive design.
A plea to let users do web things on websites. In other words, stop over-complicating everything with buckets of JavaScript.
Honestly, this isn’t wishlist isn’t asking for much, and it’s a damning indictment of “modern” frontend development that we’ve come to this:
- Let me copy text so I can paste it.
- If something navigates like a link, let me do link things.
- …
Lainey Feingold on the ongoing court proceedings against Adrian Roselli:
This lawsuit against Adrian Roselli impacts every person who cares about including disabled people in the digital world. It impacts all of us who speak, write, and advocate for digital accessibility that is fair, equitable, and ethical.
Personas are often toothless, but these accessibility personas from gov.uk are more practical and useful than most:
Each profile has a different simulation of their persona’s condition and runs the assistive technology they use to help them.
You can use these profiles to experience the web from the perspective of the personas and gain more understanding of accessibility issues.
This is the kind of press release I like.
I didn’t know the Washington Post had a design system or that the system has this good section on accessibility.
Stéphanie has gathered a goldmine of goodies:
Articles, resources, checklists, tools, plugins and books to design accessible products
In design, both in the digital and physical worlds, color should never be the sole indicator of meaning. A simple test: if your work was converted to grayscale, would it still be usable?
Andy describes life online with deuteranopia and dispenses some practical advice for designers:
If there’s any uncertainty, adding labels, icons, or textures to each meaningful color of your design will make it accessible to many more people, regardless of their ability to perceive color.
I’ve already add the search element to thesession.org, but while browser support is still rolling out, I’m being extra verbose:
<search role="search">
...
</search>Brought to you by the department of redunancy department.
I’ll remove the ARIA role once browsers are all on board. As Scott says:
Please be aware that this element landing in the HTML spec today does not mean it is available in browsers today. Issues have been filed to implement the search element in the major browsers, including the necessary accessibility mappings. Keep this in mind before you get all super excited and willy nilly add this new element to your pages.
How do we write, design, and code a link that works for everyone on every device? Let’s dive into the world of creating the perfect link, without making a pig’s breakfast of it.
I agree with the reasoning here—a new display value would be ideal.
This is a handy guideline to remember, even if there exceptions:
When a keyboard user follows a link, their focus should be taken to the new place; when a keyboard user presses a button, focus should remain on that button.
I guess the biggest criticism here is that it feels like people who believe in the superiority of single page applications and the entire ecosystem focus more on developer experience (DX) than user experience. That sounds like a dangerous blanket statement, but after all these years, I never had the feeling that the argument “better DX leads to better UX” was ever true. It’s nothing more than a justification for the immense complexity and potentially significantly worse UX. And even if the core argument isn’t DX, other arguments like scalability, maintainability, competitive ability, easier recruiting (“everyone uses React”), and cost effectiveness, in my experience, only sound good, but rarely hold up to their promises.
The primary goals of this strategy are to inform decision-making and enhance the success of accessibility-related activities within the GOV.UK Design System team.
Interestingly, accessibility concerns are put into two categories: theoretical and evidenced (with the evidenced concerns being prioritised):
- Theoretical: A question or statement regarding the accessibility of an implementation within the Design System without evidence of real-world impact.
- Evidenced: Sharing new research, data or evidence showing that an implementation within the Design System could cause barriers for disabled people.
Reminder:
emandremwork with the user’s font size;pxcompletely overrides it.