Sometimes, you might think that previous #accessibility wisdom has been superseded by new "facts". Maybe someone told you that #screenReaders don't work well with a particular design pattern, but you tested #ScreenReader X and it seemed to work fine. Perhaps you heard that an interactive HTML input doesn't persist with forced colours styling, but you tried a High Contrast mode in Microsoft Edge and it seemed to be there.

There are three considerations usually missing here:

1. How are you defining and evaluating the working state? Do you have a functional, accurate understanding of the #accessTechnology or accessibility feature you are asserting things about?
2. You tested one thing in relation to a statement about multiple things, e.g. a statement is made about screen readers, plural, and you only tested with #VoiceOver (it's always VoiceOver). Beyond posting on the web-a11y Slack, how do you propose testing more broadly, if you plan to at all?
3. Possibly the most critical at all: is this question worth its overheads? If answering it conclusively would require me to test ten screen readers with 45 speech engines, or seven browsers with 52 permutations of CSS properties, maybe following the advice is "cheaper" than determining whether the advice is still completely relevant.

Important disclaimer: this relates specifically to cases where following the advice would not actively make things worse for users.

TL;DR: when you know doing a thing won't make things bad, doing the thing is usually quicker than evaluating whether not doing the thing is also bad.

@nah @fvsch @sonny @matt But here’s the thing: Wayland would never have been made the default if, say, fonts didn’t render correctly. Not having a functional screen reader is as big an issue for people who rely on screen readers. So at some point, someone at Canonical decided that it didn’t matter that people who use screen readers would be excluded. And so they should be ashamed.

#a11y #canonical #wayland #orca #screenReaders #accessibility

People who use #ScreenReaders, imagine a feature on your instance where you can automatically hide any post that contains images/videos without alt text.

If you reply with an opinion and YOU PERSONALLY don't need alt text for accessibility reasons, I will probably block you.

#poll #ScreenReader #accessibility #a11y #blind

• It's a great idea (32%, 16 votes)
• No strong feelings (6%, 3 votes)
• It's a bad idea (6%, 3 votes)
• I don't use a screen reader (56%, 28 votes)

👁‍🗨Screen Readers support for text level HTML semantics

"A long time ago (2008) I wrote an article: Screen Readers lack emphasis. At the time, 15 years ago..."

#a11y #webDev #HTML #screenReaders

https://www.tpgi.com/screen-readers-support-for-text-level-html-semantics/

Screen Readers support for text level HTML semantics - TPGi

A long time ago (2008) I wrote an article: Screen Readers lack emphasis. At the time, 15 years ago, the screen readers tested did not signify the semantics of text...

^{Steve Faulkner (TPGi)}

👁️ short note on emoji text alternative variations

#a11y #screenReaders #emoji #unicode

https://html5accessibility.com/stuff/2022/01/17/short-note-on-emoji-text-alternative-variations/

Ensuring negative numbers are available for everyone. "The minus character (−) yields great support in most screen readers, and suffers less situational gotchas than the hyphen-minus character"

https://www.deque.com/blog/ensuring-negative-numbers-are-available-for-everyone/

Great article written by 2 of my favorite comrades.

#webdev #webdesign #a11y #html #tips #screenreaders