| ▲ | scroot 3 days ago | |
For those of us in civic tech, this is a higher priority. At the federal level especially, there are laws on the books about website accessibility compliance -- even if, at present, the powers that be are ignoring them. I have found the Web Content Accessibility Guidelines [1] to be especially useful when thinking through what I need to implement and why. It is _impossible_ to thoroughly test any of your accessibility concerns only with automated tooling. You will need to have an experienced user of screenreaders go through your site, especially if it contains complex JS enabled controls and other dynamic updates. This is because the habits of individual users and the combination of a particular screenreader application / browser can often produce different results. It's important to know what the common "patterns of use" are for, say, a JAWS user vs a VoiceOver user. Last thing I'll recommend is that if you are testing a11y yourself on a Mac using VoiceOver, do all your a11y testing in Safari. In our research, most VO users on Macs/iOS use Safari because it has the best screenreader integration on that platform, and other browsers miss basic things. | ||