week11y issue 79

Your weekly frequent11y newsletter, brought to you by @ChrisBAshton:

Emojis and accessibility: How to use them properly

  • Ryan Tan shares some tips for accessible emoji usage, mostly in terms of screen reader support, and covering a mixture of ‘design tips’ vs ‘everyday content’:
    • Design: on buttons, don’t use emojis to replace words. E.g. use “Like” rather than “πŸ‘”, which could be ambiguous.
    • Don’t use repeated emojis, e.g. “Flight plans ✈️✈️✈️” as each emoji has alt text read out by a screen reader, and this is unnecessarily noisy.
    • Put your text / call to action first, then emoji, i.e. “Let’s go πŸ‘Š” vs “πŸ‘Š Let’s go”.
    • Put your emoji at the end of the sentence, not mid-sentence.
    • Use widely-known emojis to cater for as many users as possible, e.g. “Hello πŸ‘‹” vs “Hello πŸ––”.
    • Avoid emoticons, i.e. :) vs πŸ™‚. Some emoticons are particularly difficult to understand as a screen reader user, e.g. the ‘shrug’ emoticon Β―_(ツ)_/Β―.
    • Controversially, Ryan suggests you “avoid dark or light skin colour in emoji use” and use the ‘default’ yellow for emojis that have a high contrast on both light and dark backgrounds. There’s a linked article in one of the comments that goes into this topic further, suggesting using emojis that don’t communicate race or gender at all, such as “😸”, or to always use the full range of skin tones such as “βœ‹πŸΏβœ‹πŸΎβœ‹πŸ½βœ‹πŸΌβœ‹πŸ»”.

Our development approach for accessible front-end code

  • This guide by the BBC walks through their approach for implementing front-end changes, e.g. implementing a component.
    1. Look at the screen reader UX; ask the UX designer for the required documentation if it is missing. It should cover the focus order, the announced content for screen readers, etc.
    2. Read accessibility acceptance criteria
    3. Write the HTML
    4. Check with supported assistive technology (AT). You should do this before adding CSS, and then again before and after adding JavaScript. They advise against doing all your testing at the end, as this “may be more time consuming to debug”, since you won’t necessarily know which layer caused the bug.
    5. Write automated tests for accessibility
    6. Get it reviewed (code review by engineers, design review by designers)
    7. Hold an accessibility swarm, resolve any bugs, then the component is ready for Test.

Whose nine is it anyway? (Feedback on the WCAG 2.2 working draft)

  • This article – which I read mostly for the terrible headline – was written by TPGi, an “accessibility solutions provider”, working with a consortium of big names in a11y. TPGi feel that the 9 new Success Criteria recently proposed for WCAG 2.2 all need some clarification and improvement (with the exception of 2.5.7 Dragging Movements, which TPGi are pleased with).
  • It’s a long article of recommendations, each linking to separate GitHub issues raised by TPGi. But to take an example, some feedback for “3.3.7 Accessible Authentication” includes ensuring copy-paste is not blocked: “The β€œIntent” section of the non-normative Understanding document mentions that copy-paste must not be blocked, but this is not in the text of the SC. We feel it would need to be in order to ensure that it’s a requirement.”.
  • It’s fascinating to watch the community shape the WCAG standards of the future, and inspiring that any one of us has the power to propose improvements.

This individual shows how he lives his everyday life as a blind person

  • A colleague shared this in our work Slack. Anthony S. Ferraro (asfvsion) demonstrates how he completes everyday tasks as a blind person. He covers the very basics (how to pour a cup of water; by keeping one finger over the rim of the cup and stopping pouring when he feels liquid), to the extreme (how to skateboard on a half-pipe; by mapping out the area with his cane and then basically going for it). He shows just how important tactile controls / labels are on products, e.g. the oven and washing machine, which would be extremely difficult to use otherwise.

TikTok Adds New Accessibility Overview To Provide Additional Support for Users

  • TikTok adds photosensitivity warnings to its videos, and allows viewers to opt out of viewing them. It’s also educational; warning labels are shown to creators on the specific effects that may trigger photosensitive epilepsy.
  • TikTok also offers auto captions and text-to-speech tools, and the ability to switch between animated and static thumbnails.
  • These features are described on TikTok’s Accessibility Overview page, which serve as a handy reference point.
  • Anecdotally, TikTok is often seen as very accessible compared to other social media platforms, so it’s always worth noting the improvements they’re making in this area.

Did you know that you can subscribe to dai11y, week11y, fortnight11y or month11y updates! Every newsletter gets the same content; it is your choice to have short, regular emails or longer, less frequent ones. Curated with β™₯ by developer @ChrisBAshton.

Loading...