As a web designer or developer burnout comes calling when you try to do good work, but you’re not allowed.
- You want to make the app more performant; your boss wants to fill it full of third party trackers
- You want to make the app more accessible; your boss wants you to focus on the ‘able market’ instead
- You want to word the app more clearly; your boss wants to trick users with misleading language
If you are a good developer, and a good person, asked to do shit work, you will burn out.
Smashing Podcast Episode 21 With Chris Ferdinandi: Are Modern Best Practices Bad For The Web? — Smashing Magazine
I really enjoyed this interview between Drew and Chris. I love that there’s a transcript so you can read the whole thing if you don’t feel like huffduffing it.
A heartfelt look at progressive enhancement:
Some look at progressive enhancement like a thing from the past of which the old guard just can’t let go. But to me, progressive enhancement is the future of the Web. It is the basis for building resilient, performant, interoperable, secure, usable, accessible, and thus inclusive experiences. Not only for the Web of today but for the ever-growing complexity of an ever-changing and ever-evolving Web.
Good point. When we talk about perceived performance, the perception in question is almost always visual. We should think more inclusively than that.
A score of 100 in Lighthouse or 0 errors in axe doesn’t mean that you’re done, it means that you’re ready to start manual testing and testing with real users, if possible.
This is a great short introduction to using VoiceOver with Safari by the one and only Ethan Marcotte.
Amber documents a very handy bit of DOM scripting when it comes to debugging focus management:
I think this a solution worthy of Solomon. In this case, the Gordian knot is the
select element and its inevitable recreation in order to style it.
What if we instead deliver a native select by default and replace it with a more aesthetically pleasing one if possible? That’s where the “hybrid” select idea comes into action. It’s “hybrid” because it consists of two selects, showing the appropriate one at the right moment:
- A native select, visible and accessible by default
- A custom select, hidden until it’s safe to be interacted with a mouse
The implementation uses a genius combination of a
hover media query and an adjacent sibling selector in CSS. It has been tested on a number of device/platform/browser combinations but more tests are welcome!
What I love about this solution is that it satisfies the stakeholders insisting on a custom component but doesn’t abandon all the built-in accessibility that you get from native form controls.
Smart thinking from Sara to improve usability for keyboard users by using
aria-hidden="true" tabindex="-1" to skip duplicate links:
A good rule of thumb for similar cases is that if you have multiple consecutive links to the same page, there is probably a chance to improve keyboard navigation by skipping some of those links to reduce the number of tab stops to one. The less tab stops, the better, as long as it does not worsen or compromise on other aspects of usability.
I’ve cautiously implemented this pattern now over on The Session where snippets of comments had both a title link and a “more” link going to the same destination.
input type="range" and then figure out the CSS you need (which, alas, involves lots of vendor prefixes).
This is a great case study of the excellent California COVID-19 response site. Accessibility and performance are the watchwords here.
Want to know their secret weapon?
A $20 device running Android 9, with no contract commitment has been one of the most useful and effective tools in our effort to be accessible.
Leaner, faster sites benefit everybody, but making sure your applications run smoothly on low-end hardware makes a massive difference for those users.
Here’s one simple, practical way to make apps perform better on mobile devices: always configure HTML input fields with the correct
autocompleteattributes. While these three attributes are often discussed in isolation, they make the most sense in the context of mobile user experience when you think of them as a team.
This is an excellent deep dive with great advice:
You may think that you are familiar with the basic
autocompleteoptions, such as those that help the user fill in credit card numbers or address form fields, but I’d urge you to review them to make sure that you are aware of all of the options. The spec lists over 50 values!
If you dodged an accessibility lawsuit because you have physical locations, what does it mean when those physical locations close?
As movie theaters, restaurant ordering, college courses, and more move to online-first delivery, the notion of a corresponding brick-and-mortar venue falls away. If the current pandemic physical distancing measures stretch into the next year as many think, then this blip becomes the de facto new normal.
This is a terrific explanation of the concept of accessible names in HTML, written with verve and style!
Contrary to what you may think, naming an element involves neither a birth certificate nor the HTML
nameattribute is never directly exposed to the user, and is used only when submitting forms. Birth certificates have thus far been ignored by spec authors as a potential method for naming controls, but perhaps when web UI becomes sentient and self-propagating, we’ll need to revisit that.
Chromium browsers—Chrome, Edge, et al.—are getting a much-needed update to some interface elements like the
progess element, the
meter element, and the
color input types.
This surprises me. But forewarned is forearmed.
Cargo cultism is not a strategy:
Apple and Google get it wrong just as often as the rest of us.
The minimum dependency for a web site should be an internet connection and the ability to parse HTML.
Amber runs through some HTML elements that help you provide semantic information—and accessibility—for your website: headings, paragraphs, lists, and more:
You may be aware that ARIA roles are often used with HTML elements. I haven’t written about them here, as it’s good to see how HTML written without ARIA can still be accessible.
This is a great walkthough of making a common form pattern accessible. No complex code here: some HTML is all that’s needed.