Developer Advocacy

A11y pal(ly)- crafting universally good docs

Google’s Sangeetha Alagappan talks about making your docs inclusive, what accessibility means in the context of documentation, and common pitfalls you might encounter.

Video

Summary:

  • Accessible solution delights when it blends into the product ecosystem, and it provides the user with all that they need but is still personalized to their particular abilities.

  • You should be cognizant of how you create things. You should think outside the box.

  • Accessibility is all about being creative and being surprised and just being human.

  • Write style guides.

    • Where when you set up a style guide for how you want your documentation to be,

    • It’s not only a mission statement where you tell others what you want your documentation to be, but it’s also a roadmap to show people how to get there and hold them accountable.

  • Disabilities and docs

    • Low vision

    • Colour vision deficiency

    • Blindness

    • Motor disabilities

  • Common problems

    • Lack of alternate text and or equivalents.

    • Colour contrast

    • Unnavigable by keyboard

Scribbles:

Accessibility

  • Let’s talk about accessibility and what that means for documentation. It might be a noble cause to invest in accessibility, but it’s also an incredibly selfish one because it’s an investment in your own future,

  • Because everyone will be temporarily or permanently impaired at some point in their life, and that’s according to the World Health Organization, who are very sprightly people.

  • Accessibility Isn't a zero-sum game.

  • Everybody wins when you invest in accessibility.

  • If national well-being and prosperity and societal harmony is not enough for you, accessibility also reaps economic benefits.

    • Example - Over 15% of the world have a disability. 71% of them leave an inaccessible site immediately, and very recently it’s also been a great pot for lawsuits because there’s a lot of money in that.

Disabilities and docs

  • When we talk about documentation, we talk about a narrow scope of disabilities because it is a very particular interaction that users have with documentation and product interfaces.

  • Users with low vision, so moderate to severe impairments, colour vision deficiency, mostly red-green colour blindness.

  • Users with blindness, who are more likely to use screen readers.

  • But we also talk about temporary disabilities, like changes in the device, age, situation, technical infrastructure, and temporary situations, which are not necessarily disabilities,

    • Noisy train,

    • You’re always one-handed and you’re trying to use a device with the other. And

    • On the rare sunny day in London, that one day where it’s too bright to see your screen.

Common problems

  • What we see in the documentation that makes it inaccessible is the lack of alternate text or text equivalents.

  • If a user can’t depend on visual stimuli, you need to give them an alternate text, because it gives them context

  • Or alternatively, if you don’t use all text, you can prepend an image with all of this information so that it sets the context nicely.

  • Use correct colour contrasts.

  • Having every part of your documentation navigable by keyboard.

    • Everything has to be reachable with tabs.

    • Your left and right and bottom keys, your enter key. It’s always important to check if it can be navigated by the keyboard.

  • State indicators.

    • If this were an error message, you wouldn’t be able to tell if it was red or green if you had red-green colour blindness.

    • So, the idea is to not rely on just one visual cue.

    • You should have multiple different cues, like an image with alt text that tells you that’s an error or an error text message.

    • You also shouldn’t obscure information when you’re asking a user to input something.‌

Case study 1: Bbc iPlayer

  • A couple of years ago, BBC looked at their iPlayer, the home of all your favourite shows that everybody seems to have watched and can’t stop talking about.

  • They realized that there were a lot of accessibility problems with the current interface.

  • Mostly, that TV and radio are such broad categories, but that’s what’s on the top bar.

  • Anybody who’s navigating it by keyboard had to go through everything to get to that.

  • If you’ve ever actually used a screen reader, it’s incredibly infuriating because it reads out everything.

    • Unless the page is structured minimally and optimized for a user workflow, it’s going to read out every single thing on this page.

  • The keyboard behaviour was not intuitive, so just pressing right or left, you couldn’t tell predictably where the cursor would go.

  • So they took all of that information and all of the insights from their user studies, and they realized that users require three things.

    • They need to be able to search for what they’re looking for.

    • They made it easier to scan a page and they added search functionality.

    • Broader categories that people could go to the right on the top, like channels, categories, A to Z, TV guides, so you could format how you wanted to consume this information.

    • Saving favourites.

Case study 2: Trello

  • If you use any sort of project management tool, like Canva and all of these things, it’s essentially the ability to put things into to-do lists.

  • Trello realized that when you have coloured labels, it’s kind of hard to tell if you don’t have colour.

    • They added a colour-blind friendly mode

      • You can add patterns to the edges of your labels so that you can differentiate it even if there’s no colour.

      • The response to this on Twitter was actually incredibly positive, which if you’ve ever been on Twitter, is almost a miracle.

Case study 2: NPR

  • Public radio, NPR.

  • They’ve gone and looked at all of their podcasts, and they’ve transcribed all of them so that there’s a text equivalent for all of their podcasts.

  • And then they went and looked at their metrics as all good engineers and designers do, and they realized that their search traffic increased by 6.86%.

  • Their unique visitors increased by 7.23%.

  • There was an increase in inbound links and search visibility.

  • They had increased SEO and keyword visibility.

  • Visitors who were in sound-sensitive environments or noisy environments were able to still consume podcasts.

  • As a result, they had a wider reach.

    • They have a bigger market when you’re able to because now they can easily translate their content to other languages.

    • They were able to enable search on all of their podcasts.

      • You could search text and it would reference a specific section of the audio on a podcast.

How should you write?

  • How should that affect how you write and create documentation and products as a whole?

  • You should respect the semantics because of native HTML tags like image, caption, table.

  • Always prefer the native HTML tags over custom ones that you build yourself. Don’t bury context.

  • Be upfront, summarize your intent.

  • Have multiple cues, don’t rely just on one visual cue, like colour or geographical location.

  • Most importantly, write with empathy.

    • You should approach the experience as a user.

    • You should create personas.

    • You should test edge cases‌.

Quote “accessibility’s an incredibly human discipline. You should also approach it in an incredibly human way.”

Documentation, the architecture and the hierarchy

  • Navigation tree tells you what your journey is going to look like.

  • That’s very important for screen reader users because they just need to know where to go to get what they need.

  • Always make sure that the way you use headings is consistent because that also helps screen reader users because they don’t have the visual context.

  • You should always set rules like H1 should be top-level tags, H2 should be subheadings, and you should have a guide of how you use elements.

  • You should label with context and care.

  • You should label it in a way that is sufficiently descriptive.

  • Sometimes when you write alt text for images, it doesn’t sufficiently convey what the image is.

  • You should also test a common workflow because that’s the only way you know how a product works.

  • You should go and replicate the user workflow.

Advocate for UI improvements

  • If you see something, you should say something.

  • To iterate once again, you should write with empathy.