How To Make A Strong Case For Accessibility – Smart Interface Design Patterns
Vitaly provides some sensible rebuttals.
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.
- Good design works for everyone
- Good design makes things obvious
- Good design puts users in control
- Good design is lightweight
Progressive enhancement begins with constructing a robust and universally accessible foundation, designed to cater to all users, regardless of individual or technological circumstances. From here, advanced features can be strategically layered to enhance the user experience wherever feasible. Even as these enhancements roll out, guided by the capacities of different devices, the quality of network connections, or the availability of specific APIs, the core functionalities should remain steadfast and accessible to all.
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.
This isn’t an opinion piece. This is documentation.
You can’t JavaScript your way out of an excess-JavaScript problem.
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.