N recommendations to improve accessibility in the fediverse and ATmosphere (DRAFT)
DRAFT! Work in progress!
Feedback welcome!
Here are some work-in-progress recommendations based on initial feedback to Improving accessibility in the fediverse and the ATmosphere. these!
For everybody
- Learn to avoid common accessibility mistakes
- Take the time to compose good alt text for your images if you're able to – and if not, ask others for help
- When somebody shares an image without alt text, provide alt text in a reply (instead of giving them a hard time)
For developers and software teams
Note that people who aren't developers or core team members can contribute to most of
- Provide easy-to-find accessibility-related information.
- Provide information in multiple formats and languages to accommodate different needs and preferences
- Consider your landing page, getting-started guide, tutorials, and other web sites as well as the software
- Do a first pass of accessibility checking with a screenreader and free tools
- Do usability testing with disabled people
- Ensure there's an easy (and accessible!) way for people to report accessibility problems
- Think about initial settings from an accessibility perspective
- Provide a flow for people to suggest alt text
For everybody
Learn to avoid common accessibility mistakes in your posts
Too many emoji can make text a horrible experience through a screenreader or other assistive technologies. So can ASCII art, using special unicode charcters for bold and italics, and single-case hashtags (as opposed to camelCase, which screenreaders are more likely to handle properly). Images without alt-text, or videos without captions or transcripts, won't work for people using assistive technologies.
The suggestions in Adrian Roselli's Improving Your Tweet Accessibility apply just as much to Mastodon and Bluesky (and the videos of how these inaccessible constructs sound through screen readers are really worth checking out).
Take the time to compose good alt text for your images if you're able to -- and if not, ask others for help
Nielsen Norman Group's Alt Text: What to Write and WebAIM's Alternative Text page are good guidelines for composing alt text. For the mechanics of how to do this, see Manning Krull's Alt text 101 for Bluesky and infosec.exchange's FAQ for Glitch, Mastodon, and compatible software. To reduce the chances you accidentally forget, many platforms have settings to warn before posting an image without alt text; on Bluesky and compatible software like blacksky.community, it's under Settings / Accessibility (check the box next to "Require alt text before posting).
If you can't provide alt text (because you just don't have the spoons, or because you're running into accessibility problems in the software), consider including the #AltText4Me hashtag in your post. With luck, somebody will reply with alt text. If you're on Mastodon or some other platform that allows editing posts, you can go back and edit your image to include the alt text; even if that's not possible, people will be able to see the alt text in the reply.
When somebody shares an image without alt text, provide alt text in a reply (instead of giving them a hard time)
Most people aren't used to including alt text on images, and may not even know it's an option. So replying with the alt text helps anybody who needs it. It's also an opportunity to help the poster learn new behavior (for example, if they're on Mastodon by letting them know how to edit their post and include the alt-text).
And it's often best to resist the temptation to give the original poster a hard time for not including alt text! Alt text functionality isn't always fully accessible (this was a problem on Mastodon until the latest release, and even now there are still some edge cases that don't work well with keyboard-only navigation); and sometimes people just don't have the energy to do it. Not only that, scolding is less likely to lead to behavior change than encouragement!
For software and product teams
Provide easy-to-find accessibility information.
Make it easy for people using user software with assistive technology to find accessibility-related tutorials, information about settings, and any tips (or gotchas) for use with assistive technology.
For example, Veronica Lewis' Bluesky Accessibility Features For Low Vision and the Apps section of Robert Kingett's Fediverse for writers/readers ve a lot of valuable information, but without any linkage from the software's main page and/or onboarding process they're not easy to find. One good example of important info that's not obvious to new users is the Bluesky setting to turn off video autoplay (an accessibility nightmare) isn't under the accessibility settings, but instead under under Content and Media).
Provide information in multiple formats and languages to accommodate different needs and preferences.
Different formats are better or worse for some people, so try to provide information in text, audio (with transcripts), short video (with captions and/or transcripts) – ideally in multiple langauges as well. Information about PDS migration in the ATmosphere illustrates several good examples, with Sharpie's captioned videos on using PDS Moover and Using missing.pdsmoover.com to Recover Missing Images and Posts, Clinton Bowen's transcripted short video on using tektite.cc, sprout's textual How to Migrate to Blacksky, and victoria's Lista: PDS independente (in Portuguese).
This won't all happen overnight; text-only is fine to start with, and so is starting with a single language and then translating to others. Sharing the longer-term goal with the community may be a good way to encourage contributions.
Consider your landing page, getting-started guide, tutorials, and other web sites as well as the software.
It's all important! And, if people can't make it through your landing page, they won't even get to the point where they're downloading the software.
Do a first pass of accessibility checking with a screenreader and free tools
To be clear, this isn't a substitute for a more in-depth testing or an accessibility audit. Still, it's a useful way to start making progress.
- Use your product with different screenreaders. WebAIM's 2024 survey reports that NVDA (Windows-only) and Jaws are by far the most popular, with Voiceover (Apple-only) as #3; TalkBack is most popular on Android. WebAIM's pages on using NVDA, Jaws, VoiceOver, and TalkBack to evaluate web accessibility are good starting points; so are Harvard Digital Accessibility's pages on getting started testing with NVDA, Jaws, VoiceOver, and TalkBack.
- Free analysis tools like WAVE Web Accessibility Evaluation Tools and WebAIM's contrast checker can find a lot of easy-to-fix problems. It's important to keep the limitations of these tools in mind; as Beau Vass' A false sense of accessibility: What automated testing tools are missing discusses, automated tools typically only find 20-30% of accessibility problems.
Do usability testing with disabled people.
Web Accessibility Initiative's Involving Users in Evaluating Web Accessibility and Nielsen Norman Group's How to Conduct Usability Studies for Accessibility have some good suggestions.
Ensure there's an easy (and accessible!) way for people to report accessibility problems.
Think about initial settings from an accessibility perspective.
For example, should videos auto-play by default? And if your software warns about missing alt-text when posting an image, consider making that the default (and explaining why it's so important); most people coming from commercial social networks aren't used to doing this, so it's an easy (and gentle) way to encourage them.
If different settings are better for people using assistive software, either make it very easy to select the accessibility-friendly settings up front or make them the default for everybody; requiring people to navigate through settings on multiple screens is likely to be a barrier.
Provide flows for people to suggest alt text
When a post with image or video doesn't have alt text (or only has very minimal alt text), provide a flow for people to suggest alt text, the original poster to approve it, and update the alt text of the original post.
Fedi today has a low tech version of this involving replies with the hashtag #AltText4You; if the original poster approves, they can cut-and-paste the text, edit the original post and update the alt-text – a lot better than nothing, but it could be even smoother. You can approximate that the ATmosphere using PDSls to do the editing but it is even more challenging.
The bluesky-social issue Community-Submitted Alt Text is one path to addressing this; the Mastodon issue Security option to specify another account(s) to add alt-text to your posts is also potentially relevant.