HN Academy

I have had a lot of success with this course (Web Accessibility, by Google): https://www.udacity.com/course/web-accessibility--ud891

> In this course you’ll get hands-on experience making web applications accessible. You’ll understand when and why users need accessibility. Then you’ll dive into the "how": making a page work properly with screen readers, and managing input focus (e.g. the highlight you see when tabbing through a form.) You’ll understand what "semantics" and "semantic markup" mean for web pages and add ARIA markup to enable navigating the interface with a range of assistive devices. Finally, you’ll learn styling techniques that help users with partial vision navigate your pages easily and reliably.

Not GP, but dev learning a11y too.

I'm just going though a web course on this which is pretty good.

https://www.udacity.com/course/web-accessibility--ud891

I think moving focus into the modal is pretty helpful

Here's the video on focus

https://www.youtube.com/watch?v=BoAsayPVogE&t=65

You can set tabindex="-1" on the header of the dialog, and move focus to that. (Also set outline: none on the dialog, but not anything else). Then you can just call focus() on it, which isn't too hard.

I think it's okay if you don't remove the ability to focus on all the background stuff if the focus is at least moved into the modal.

I think for aria-labels for buttons, the best way to check this is to either use chromevox/ a screenreader and see what it says for the button. You can also inspect element, and go to the aria tab in chrome dev tools, and see what aria name is computed. You can see the order it takes them from, with aria-labelledby, aria-label, then contents.

If the name is reasonable, then you don't need a aria-label at all.

⬐ tekkk

Thanks, a lot appreciated!