4 ms·
Hey, thank you for your insight into the life of blind users. I have often wondered if my sites that I've been part of building have been accessible but without
by tekkk 7y ago
Hey, thank you for your insight into the life of blind users. I have often wondered if my sites that I've been part of building have been accessible but without proper guidance or customer requirements, nobody has really cared that much to check out.
Lately I have been part of building a quite popular website in my native country, and this time, as I have had more autonomy than before, decided to go ahead and add as much accessibility helping markup and proper elements as possible. Eg. everything that can be clicked is now a button (no more divs with onClick-handlers) and by the way, is adding tabIndex to divs even sufficient for triggering clicks? Since by default the Enter-key is not bound to trigger the click-event for elements other than buttons and links (I assume).
Anyway, I went ahead and added as much accessibility I could, but some things were bit too much of extra work that I decided not to add them. So I was just wondering, how bad is it when modals don't automatically capture the focus and you can't really travel into them unless moving all the way to end of the document (where the element lies)? From what I glanced from the aria spec, the focus should immediately move into the modal and get trapped where you can only by invoking an action (eg esc-key, click x-button or submit) dismiss them.
Also how important are the aria-labels for buttons and such? Should everything worth noticing be annotated? Or can you guess from say the button text what they are for. Also I read somewhere that inputs should always have labels, but sometimes it's problematic to add them eg dates with three inputs with only one label "Birthdate". Can I supplement the label with some aria-property instead?
Sorry for asking so many long questions, these things have been on my mind a lot and I really haven't had anyone to tell me if the accessibility fields I have added were correct or not. It's quite annoying how confusing the spec is and how difficult it's to know if the aria properties are correct/make sense or not. Eg how many aria-haspopup etc properties should a dropdown have and which of its elements have which.
- Tyr42 7y agoNot 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 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 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 7y agoThanks, a lot appreciated!
- mltony 7y agoI actually work more in backend area, so I am not that familiar with accessibility standards in HTML. I am only a user there. But looks like others have already answered some of your questions.
- tekkk 7y agoNo problem, and I'm happy that this came up so that I can try my best to make things better for users like you :).