Testing a client travel site I see a static weather travel alert warning that is very visually marked as important on the screen but the screen reader user would have no idea of its importance because there are no accessibility API semantics communicated.
CSS Generated Icons Cause VoiceOver for iOS Bugs
There is also a CSS Generated Content glyph icon to indicate visually that this is a warning or error message. The text Travel Alert: is red and bold but it has no heading semantics.
I think the string “Travel Alert:” serves as the text alternative for the warning icon itself so you don’t need additional alt text.
VoiceOver for iOS has a bug or a feature, not sure, that causes it to speak “Face Screaming in Fear” when focused on this bootstrap CSS generated warning icon! That’s crazy right! 🙂 I’m serious go test it out. http://pauljadam.com/demos/role-alert.html
aria-hidden=true Prevents VoiceOver for iOS from Speaking CSS Generated Content Icons
Bootstrap code for this had aria-hidden=true already correctly applied to the span that generates the icon but I’ve seen this bug out in the wild on many client sites so glad to see the solution works! Try the before and after example.
See Details Link Purpose Determinable?
Link Purpose is another issue where a screen reader user could not determine the purpose of the See Details link if they just TAB to the link and only hear “See Details, link”. What exactly are the details I’ll be seeing if I click the link? I recommend placing the aria-describedby attribute on the See Details link with a value that points to the ID reference of the full travel alert string text. This way the actual details text of the travel alert will serve as the accessible description in the a11y API.
Simple Heading with WAI-ARIA role=heading and aria-level=1
Travel Alert: to me serves as a heading that sections off a chunk of content below it so it needs semantics. I’m fine with not changing the HTML tag here and we can just apply role=heading and aria-level=1 to the <strong> element and BOOM it’s a heading! At least to the screen reader users and the a11y API 🙂
But can we put role=alert on static text alerts?
So we fixed the missing heading, we fixed the warning icon issue, fixed the link purpose issue… But I had this idea that this really could use even more semantics to help convey its importance because it does not pop up after page load or flash on the screen so there’s no ARIA Live Region because there’s no text being inserted or removed from the DOM.
The Mozilla Developer Network Using the alert role article is the first google result and gave me the idea based on example 1, https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_alert_role.
Example 1: Adding the role in the HTML code
Your form could not be submitted because of 3 validation errors.