> Now an assistive technology user has an equal (and maybe even better) conceptual map of the content and actions they can take on this website compared to a non-assistive technology user. They can get a quick overview of everything on the site, easily navigate to the section of the page they want, and quickly find what they are looking for.
Often there's substantial overlap between improving accessibility and helping "power users".
Sometimes that overlap can help convince managers to spend more time on these kinds of features.
(Unless maybe your whole model is herding people to ads or "promoted" stuff.)
The keyboard navigation that is required to support the WCAG spec is greatly appreciated by me, even though I am fully sighted and don’t use a screen reader.
This was actually the easiest way to sell a management on some of the time we were spending making our latest project accessible. We had time allotted for power user workflows. If you’re implementing keyboard shortcuts there is likely something about that particular type of action in WCAG.
Of course theirs more to it than that. One of the hardest things was coming up with a good strategy for handling hover/focus/active states that didn’t look gaudy to management. The new :focus-visible selector can help where it’s supported, but getting our designed to think about these additional states when designing components helped a lot.
Often there's substantial overlap between improving accessibility and helping "power users".
Sometimes that overlap can help convince managers to spend more time on these kinds of features.
(Unless maybe your whole model is herding people to ads or "promoted" stuff.)