Skip to main content

Search

Items tagged with: accesstechnology


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.