accessibility discussion time. I keep seeing strong opinions about automated audit scores, and both sides sound very suree of themselves, for a government contractor's site, we want to do the right thing, not just teh thing that looks good on a checklist, how do you decide what actually improves life for people using keyboards, screen readers, magnifiers or voice control?? practical advice welcome, especially things a small team can actually keep doing. im about to throw this thing out the window lol
client wants automated audit scores on a government contractors site. should i push back?
no regular testers yet, but we could hire someone for a usability session on a government contractor's site. sorry for the wall of text lol
ahh classic infinite scroll makes footers unreachable and loses position when navigating back. offer a load more button or pagination, and move focus sensibly when new content apperas.
exact same thing happened to my work pc last month worked for me anyway 🤷
oh ive been there lol custom dropdowns are a common source of trouble. Native
<select>elements come with keyboard support and screen reader semantics for free... if you need a custom one, follow the ARIA patterns closely and test with real assistive technology. worked for me anyway 🤷overlay widgets cant fix inaccessible markup reliably. many screen reader users already have their own settings and tools, and overlays sometimes interfere with them :/ the money is usually better spent fixing the underlying HTML: headings, labels, focus order, alt text. hope that helps :)
@vcosta omggg we're doing keyboard and screen reader testing on key flows before launch. Already found issues the automated tool missed. seriously made my day 😭🙏
Reply to this topic
Sign in or create an account to reply.