[dylanb]@karlgroves I would not say “a lot”, I dabbled with making the standard Google map UI keyboard and screen reader accessible as an “overlay"
[dylanb] my recommendation with maps is: think about the use case and see whether you can create a UI that does not rely on the actual map display because if you can, you will probably end up with a user interface that is better for everyone
[dylanb] maps are often just glommed onto pages because it is easy to do and not because it is the best solution
[caesar] Question re: 3.3.2 Labels or instructions... if the instruction text is just plain text in the form (but occurs prior to the field), doesn't that pass? Or does it have to be part of the label, or associated with the field using aria-describedby?
[michiel] Caesar: Note: When labels are provided for input objects, the input object's relationship to the label (or to redundant text serving as the label) must be programmatically determinable or available in text per Understanding Success Criterion 1.3.1 Info and Relationships.
[caesar] Thanks @michiel ... sorry, I wasn't clear. What if the instruction is separate to the label? E.g. there's a "Password" label, but then a separate instruction describing the format requirements?
[michiel] An aria-describedby would be helpful in that case.
[caesar] Helpful, sure. But is there any expectation that "static text" in a form be explicitly associated with the interactive form elements? Or are SR users expected to use the form using a combination of browse mode and forms mode? (i.e. can't just tab between fields, because you might miss the static content)?
[caesar] I've seen some solve it by assigning tabindex="0" to the static text, for instance.
[michiel] I would say that users expect to get all the information necessary when they tab into the field. However, I'm not a screen reader users, so you might be better off asking them :).
[skymaiden] hello! quick question – is it OK to use both a title and aria-label? is it ok for them to be identical? (i figured aria-label would be read by screen readers, and the title is shown on rollover)
[tink] For screen reader users, the ARIA will trump the title attribute.
[tink] But depending n the type of element you're applying them to, you may not want to use the title attribute at all.
[iandevlin] Hello! I too have a quick question...if an input field has aria-hidden="true", should it also have an associated label? I would think not, however I am of course no expert.
[michiel] iandevlin: why does it have aria-hidden?
[iandevlin] Because it is only being used for adding a suggestion in the background behind what a user is typing.
[michiel] tink: the tables entry is disabled by default. To enable: Settings.app → General → Accessibility → VoiceOver → Rotor.
[tink]@iandevlin if the field isn't visible/usable by *anyone, then no it doesn't need a label.
[iandevlin] Yeah, it is visible if you can see it, but it shows duplicate information, as the suggestions are also displayed elsewhere, but the top one is shoved under the main input where the user is entering their search term. This is why I was wondering if it is needed, as the info is duplicated.
[iandevlin] Ideally this wouldn't even be an input, but it was added in the past to make the styling easier...
[tink] If it's visible I wuldn't hide it from screen reader users.
[iandevlin] Yeah, this is what I was thinking, I just wanted confirmation, thanks.
[tink] So would remove aria-hidden, give it a (visible) label, and call it done.
[michiel] iandevlin: is this like the google search? Where they have like a placeholder behind the main input? With an auto complete menu underneath?
[iandevlin] Yes michiel, something similar to that.
[michiel] Because in that case I would think it’s safe to hide it, but announce the information in a passive way.
[iandevlin] Hmm, ok. Will look into this too.
[iandevlin] Thanks again.
[michiel] Well, it’s useful information in that if you hit enter it will search for what is showing as placeholder text right? So it would make sense to make that feature available to AT, too.
[michiel] Maybe someone with more experience with such components can give some more concrete feedback.