Accessibility in knowledge bases

Hi team,

I was reading https://support.discord.com/hc/en-us/articles/1500010454681-Accessibility-Settings-Tab, and there are step by step instructions using ‘>’ to dictate the steps. Screen readers can read out less and more than signs in full, (it literally speaks “more than”).

Web content accessibility guidelines (WCAG) 2.3 is the gold standard on writing. Generally, instructions that have an order of operations should be part of a numbered list or list of steps (step 1, then step 2, etc). Lists that don't require a logical order should be bullets.

I'd consider creating a style guide or library of accessible document and file templates (or even just ‘blocks’, for formatting specific sections, of lorem ipsum) to build up articles like this. Formats that look plausible to the average non-disabled reader are hard to spot and easy to miss.

Sincerely, a disabled ex-knowledge manager.

Ironic Empress

17 Maj 2024 10:20

Bonus points since I forgot it the first time around. I'd recommend avoiding common terms that may be inherently ableist or abiguous that also get overlooked in writing instructions:

- ‘click’ on something, some people don't use a mouse and ‘click’ it. Select is a better suited instruction.

- ‘look’ or ‘see’ instructions/ diagram/ video. Again, not everyone sees, use directing language like ‘refer to' or ‘X diagram explains XYZ’, or ‘X section covers X topic’.

- ‘here’ (usually used to embedd a link in text)… Where's here?! You get the idea. Embedded links work best when they highlight existing text on what their purpose is or where they go eg: ‘visit our contact page (link here) to do X’. Standalone links should have surrounding context eg: ‘below is a list of X sites (list sites). Bonus points for alt text advising if the link is external, or to a document etc.

Kommentarer