34 items tagged “accessibility”
2024
Serving a billion web requests with boring code (via) Bill Mill provides a deep retrospective from his work helping build a relaunch of the medicare.gov/plan-compare site.
It's a fascinating case study of the choose boring technology mantra put into action. The "boring" choices here were PostgreSQL, Go and React, all three of which are so widely used and understood at this point that you're very unlikely to stumble into surprises with them.
Key goals for the site were accessibility, in terms of users, devices and performance. Despite best efforts:
The result fell prey after a few years to a common failure mode of react apps, and became quite heavy and loaded somewhat slowly.
I've seen this pattern myself many times over, and I'd love to understand why. React itself isn't a particularly large dependency but somehow it always seems to lead to architectural bloat over time. Maybe that's more of an SPA thing than something that's specific to React.
Loads of other interesting details in here. The ETL details - where brand new read-only RDS databases were spun up every morning after a four hour build process - are particularly notable.
Transcripts on Apple Podcasts (via) I missed this when it launched back in March: the Apple Podcasts app now features searchable transcripts, including the ability to tap on text and jump to that point in the audio.
Confusingly, you can only tap to navigate using the view of the transcript that comes up when you hit the quote mark icon during playback - if you click the Transcript link from the episode listing page you get a static transcript without the navigation option.
Transcripts are created automatically server-side by Apple, or podcast authors can upload their own edited transcript using Apple Podcasts Connect.
Cally: Accessibility statement (via) Cally is a neat new open source date (and date range) picker Web Component by Nick Williams.
It’s framework agnostic and weighs less than 9KB grilled, but the best feature is this detailed page of documentation covering its accessibility story, including how it was tested—in JAWS, NVDA and VoiceOver.
I’d love to see other open source JavaScript libraries follow this example.
Guidepup. I’ve been hoping to find something like this for years. Guidepup is “a screen reader driver for test automation”—you can use it to automate both VoiceOver on macOS and NVDA on Windows, and it can both drive the screen reader for automated tests and even produce a video at the end of the test.
Also available: @guidepup/playwright, providing integration with the Playwright browser automation testing framework.
I’d love to see open source JavaScript libraries both use something like this for their testing and publish videos of the tests to demonstrate how they work in these common screen readers.
2023
Ice Cubes GPT-4 prompts. The Ice Cubes open source Mastodon app recently grew a very good “describe this image” feature to help people add alt text to their images. I had a dig around in their repo and it turns out they’re using GPT-4 Vision for this (and regular GPT-4 for other features), passing the image with this prompt:
“What’s in this image? Be brief, it’s for image alt description on a social network. Don’t write in the first person.”
New Default: Underlined Links for Improved Accessibility (GitHub Blog). “By default, links within text blocks on GitHub are now underlined. This ensures links are easily distinguishable from surrounding text.”
You can stop using user-scalable=no and maximum-scale=1 in viewport meta tags now. Luke Plant points out that your meta viewport tag should stick to just “width=device-width, initial-scale=1” these days—the user-scalable=no and maximum-scale=1 attributes are no longer necessary, and have a negative impact on accessibility, especially for Android users.
The anatomy of visually-hidden (via) James Edwards provides a detailed breakdown of the current recommended CSS for hiding content while keeping it available for assistive technologies in the browser accessibility and render trees. Lots of accumulated tricks and screenreader special cases in this.
2022
WebAIM guide to using iOS VoiceOver to evaluate web accessibility (via) I asked for pointers on learning to use VoiceOver on my iPhone for accessibility testing today and Matt Hobbs pointed me to this tutorial from the WebAIM group at Utah State University.
Weeknotes: Distracted by Playwright
My goal for this week was to unblock progress on Datasette by finally finishing the dash encoding implementation I described last week. I was getting close, and then I got very distracted by Playwright.
[... 892 words]2021
A Complete Guide To Accessible Front-End Components. I’m so excited about this article: it brings together an absolute wealth of resources on accessible front-end components, including many existing component implementations that are accessible out of the box. Date pickers, autocomplete widgets, modals, menus—all sorts of things that I’ve been dragging my heels on implementing because I didn’t fully understand their accessibility implications.
2019
Using the HTML lang attribute (via) TIL the HTML lang attribute is used by screen readers to understand how to provide the correct accent and pronunciation.
2018
If you wrap your main content – that is, the stuff that isn’t navigation, logo and main header etc – in a
tag, a screen reader user can jump immediately to it using a keyboard shortcut. Imagine how useful that is – they don’t have to listen to all the content before it, or tab through it to get to the main meat of your page.
2017
How technology helped a blind athlete run free at the New York Marathon. Fascinating piece on technology to help blind people better navigate the world—combing GPS and chest-mounted ultrasonic sonar.
Skip the title text! Nobody uses them – they don’t work on touch screens and on desktop they require that the user hovers for a while over an image, which nobody does. Also, adding a title-text makes some screen readers both read the title-text and the alt-text, which becomes redundant.
Alt-texts: The Ultimate Guide. By Daniel Göransson, a web developer with vision impairment who uses a screen reader. This is the best, most practical guide to writing image alt text I’ve seen. Just one of the neat tips contained within: consider ending your alt text in a period, so the screen user knows to pause.
2010
My First Week with the iPhone. A blind user describes the experience of using VoiceOver on the iPhone, including the joy of discovering the Color Identifier app which speaks the names of colours picked up by the iPhone’s camera. “ I used color cues to find my pumpkin plants, by looking for the green among the brown and stone. I spent ten minutes looking at my pumpkin plants, with their leaves of green and lemon-ginger.”
2009
Accessibility and Degradation in Cappuccino. Ross Boucher from 280 North responds to Drew McLellan.
The Cost of Accessibility. Drew McLellan comments on the seemingly inevitable march towards JavaScript dependent applications, and argues that JavaScript frameworks such as Cappuccino have a duty to integrate accessibility in to their core.
2008
Accessibility Experiment. Joe Walker asks what would happen if we threw away the idea of serving the same accessible site to every user and instead tried building specific versions aimed at different disabilities.
Capital Radio’s London Guide. Worth pointing out: the search / map interface on this page is one of the best examples of progressive enhancement I’ve ever seen. Try disabling JavaScript and see what happens. It seems like most developers just can’t be bothered with this kind of attention to detail these days, which disappoints me.
Microformats and accessibility: the soap opera that never ends. “Be sure to tune in next week, when we’ll drown a leading accessibility expert to see if she’s a witch.”
Removing Microformats from bbc.co.uk/programmes. “Until these issues are resolved the BBC semantic markup standards have been updated to prevent the use of non-human-readable text in abbreviations.”
2007
google-axsjax (via) “The AxsJAX framework can inject accessibility enhancements into existing Web 2.0 applications using any of several standard Web techniques”—including bookmarklets and Greasemonkey. The enhancements conform to W3C ARIA, supported by Firefox 2.0 and later.
Why Accessibility? Because It’s Our Job! “A chef must care about health, a builder must care about safety, and we must care about accessibility.”
Ignorance and inspiration. I’m pretty gobsmacked at the levels of ignorance about web accessibility out there—it’s not that hard people! I’m obviously more out of touch with mainstream developers than I thought; I was under the impression that people had generally got the message.
Google Maps, HTML version. Google’s mostly undocumented accessible version of Google Maps. Robin Christopherson demonstrated this yesterday at FOWA.
The longdesc lottery. Mark Pilgrim is now writing for the WHATWG blog. Here he makes the case for replacing the longdesc attribute with a better solution, based on ten years of developer ignorance and misuse. As always with that site, check the comments for a microcosm of the larger debate.
html4all. New mailing list / advocacy group focusing on accessibility issues relevant to HTML 5. This is something that the core HTML 5 group have taken a lot of criticism for, although it’s unfair to say that they don’t care about accessibility (they are however challenging a lot of sacred cows).
I've actually been using the latest version of JAWS recently, as part of my work on HTML5. From a usability point of view it is possibly the worst software I have ever used. I'm still horrified at how bad the accessibility situation is. All this time I've been hearing people worried about whether or not Web pages have longdesc attributes specified or whatnot, when in fact the biggest problems facing blind users are so much more fundamental as to make image-related issues seem almost trivial in comparison.