How’s it going, I'm a Adam, a Full-Stack Engineer, actively searching for work. I'm all about JavaScript. And Frontend but don't let that fool you - I've also got some serious Backend skills.
Location
City of Bath, UK 🇬🇧
Education
10 plus years* active enterprise development experience and a Fine art degree 🎨
I'm fairly certain that CSS content and by extension attr() is not read by most screen readers + browser combination, being part of presentation rather than real content. I'd reconsider the recommendation unless I'm wrong then find tell me to pipe down. 😁
From accessibility point of view I meant that when we add such content like tooltip on hover, what we can do is add the content in aria-label which will be read by the screen reader and then make use of the samearia-label through are CSS with attr() for the normal flow. In that way we can have consistent content throughout.
Probably should've explained better 🙂
How’s it going, I'm a Adam, a Full-Stack Engineer, actively searching for work. I'm all about JavaScript. And Frontend but don't let that fool you - I've also got some serious Backend skills.
Location
City of Bath, UK 🇬🇧
Education
10 plus years* active enterprise development experience and a Fine art degree 🎨
Case 1 reads "paragraph, hello a11y text, important info"
Case 2 reads "paragraph, hello a11y text" only but displays the same as case 1.
If it where me, I would stick to a JavaScript solution with real markup, role and avoid aria-label at all costs, good UX and good content do not need aria-label.
I don’t work with computers, never have, but I love learning new technologies. Plus, I would like to know why people are following my dashboard/profile when I post virtually nothing.
How’s it going, I'm a Adam, a Full-Stack Engineer, actively searching for work. I'm all about JavaScript. And Frontend but don't let that fool you - I've also got some serious Backend skills.
Location
City of Bath, UK 🇬🇧
Education
10 plus years* active enterprise development experience and a Fine art degree 🎨
No? aria-label attributes still very much a day to day support attribute. They are just not great to use unless you have to, your markup should describe your SR journey without needless overides. Do you have any specification to suggest they are out of date?
If what you're doing is purely decorative or there is accompanying text, etc., then no, it's not a, "You can't use it because it's inaccessible." There's certainly use cases for CSS content, for example, that are perfectly fine. It just depends on their use.
How’s it going, I'm a Adam, a Full-Stack Engineer, actively searching for work. I'm all about JavaScript. And Frontend but don't let that fool you - I've also got some serious Backend skills.
Location
City of Bath, UK 🇬🇧
Education
10 plus years* active enterprise development experience and a Fine art degree 🎨
Not what I'm saying. And I quote "This method could be really helpful with accessibility purposes." This is not true.
In the codepen example the tooltip will never be explained to blind users, so in affect, sighted users will get the context but not the blind user. So I stand by what I said. CSS content should be used with care.
Also this is not an I'm right your wrong, I'd love to be wrong because I'd use content more and JavaScript solutions less. Instead this is an ask to remove the quoted text because there is a lot of confusion on how to do accessibility.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I'm fairly certain that CSS content and by extension attr() is not read by most screen readers + browser combination, being part of presentation rather than real content. I'd reconsider the recommendation unless I'm wrong then find tell me to pipe down. 😁
From accessibility point of view I meant that when we add such content like tooltip on hover, what we can do is add the content in
aria-labelwhich will be read by the screen reader and then make use of the samearia-labelthrough are CSS withattr()for the normal flow. In that way we can have consistent content throughout.Probably should've explained better 🙂
Hi Anya, thanks for the post, do you mean like this?
Case 1
Case 2
Case 1 reads "paragraph, hello a11y text, important info"
Case 2 reads "paragraph, hello a11y text" only but displays the same as case 1.
If it where me, I would stick to a JavaScript solution with real markup, role and avoid aria-label at all costs, good UX and good content do not need aria-label.
aren't the 'aria-label' tags outdated now?
No? aria-label attributes still very much a day to day support attribute. They are just not great to use unless you have to, your markup should describe your SR journey without needless overides. Do you have any specification to suggest they are out of date?
If what you're doing is purely decorative or there is accompanying text, etc., then no, it's not a, "You can't use it because it's inaccessible." There's certainly use cases for CSS content, for example, that are perfectly fine. It just depends on their use.
Not what I'm saying. And I quote "This method could be really helpful with accessibility purposes." This is not true.
In the codepen example the tooltip will never be explained to blind users, so in affect, sighted users will get the context but not the blind user. So I stand by what I said. CSS content should be used with care.
Also this is not an I'm right your wrong, I'd love to be wrong because I'd use content more and JavaScript solutions less. Instead this is an ask to remove the quoted text because there is a lot of confusion on how to do accessibility.