4 ms·

I like this approach. It makes me wonder though, what about <i>, <em>, <dfn>, <cite>, etc.? They all look the same by default and as far as I know there is no U

by mk12 2y ago

I like this approach. It makes me wonder though, what about <i>, <em>, <dfn>, <cite>, etc.? They all look the same by default and as far as I know there is no UX advantage to using them properly. Do screen readers differentiate them? It doesn’t seem necessary for accessibility when sighted users can’t tell the difference either.

edent 2y ago
If you use `<i lang="la">sic transit gloria mundi</la>` then your screen reader should read the text in a Latin accent rather than munging whatever your default language is. As for the rest, they look the same now. But HTML is supposed to be future proof. Suppose, in the future, people prefer emphasised text to slant backwards, definitions to hover holographically, and cites to render directly to your neural link. Or, suppose right now you want to screen-scrape a page and get all the definitions. That's why I use semantic HTML.
troupo 2y ago
Screen readers should read those tags differently. em is emphasis, cite is citation etc.
- extra88 2y ago
  In theory they could, in practice they don't because almost nobody writing those elements pays attention to that level of detail or use them solely for a visual styling effect that has no bearing on understanding the meaning of the content.
kaoD 2y ago
The semantics are indeed different in screen readers and the elements will be announced differently and behave differently in the accessibility tree (by virtue of having ARIA roles like e.g. "term"[0] or "definition"[1]). Note that ARIA roles change drastically how elements are announced -- a screen reader would take forever to announce elements if they were not scoped by their role because it would have to announce what an item is not (e.g. if it's unchecked, which is announced for "checkbox" roles, which can be and often are <span>s). ARIA roles make a bunch of ARIA attributes hidden (or, conversely, shown) in the accessibility tree. It also gives context to additional ARIA attributes like aria-details[2] because now the screen reader knows that the details are the definition or whatever, and will announce those appropriately. Using semantic elements allows you to have the proper ARIA roles (and thus the accessibility tree be properly scoped) without thinking too much or polluting your DOM tree with aria-* attributes. There are also some other semantic-related benefits. E.g. from <dfn>'s MDN page[1] "if you include an id attribute on the <dfn> element, you can then link to it using <a> elements. Such links should be uses of the term, with the intent being that the reader can quickly navigate to the term's definition if they're not already aware of it, by clicking on the term's link." I know you can already id-link to a simple <span>, but the thing is the screen reader would be able to announce that the link is to a definition so the user is already aware of the link purpose even before clicking it (unsure if any do this, but they could). Or maybe the user agent could build up a list of definitions automatically and allow you to quickly look up them, even if they are not explicitly linked. Most importantly: you might think that sighted users cannot tell the difference between the default styling of all those elements, but they often can by virtue of what they are visually surrounded with and other contextual clues that are not available while using a screen reader. E.g. `<cite>` is often surrounded by other visual cues that might not be obvious to screen reader users which have a very local and narrow contextual scope (you can only hear elements one at a time, while visual users can see a bunch of context at a glance). Also, sighted navigation is much faster than navigating via keyboard+narration so the additional affordances really help non-sighted users. Imagine having to wait for a whole paragraph to be narrated to get to some textual clue near the end of the paragraph, or even further down the content... or worse, above the current content (think an <h2>Definitions</h2> for example) which will normally not get visited while you navigate piecewise. It's very hard (impossible?) to read/navigate diagonally with a screen reader. We get so much instant info visually that we take for granted and it's just not there for screen reader users. Lastly, you can style those differently in CSS even if the default user agent stylesheet does not. E.g., by giving <dfns> a dashed underline or a different mouse cursor. I know you can do that by manually annotating <span>s with classes but the thing is... you don't need to. So you can give additional visual affordances to sighted, but also to cognitively-impaired or partially-blind users too. [0] https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/term_role https://developer.mozilla.org/en-US/docs/Web/Accessibility/A... [1] https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/definition_role https://developer.mozilla.org/en-US/docs/Web/Accessibility/A... [2] https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-details https://developer.mozilla.org/en-US/docs/Web/Accessibility/A... [3] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dfn https://developer.mozilla.org/en-US/docs/Web/HTML/Element/df...
- extra88 2y ago
  There are many roles that exist that are not actually conveyed by screen readers. Either they're obscure and so seldom used that no one cares if the role is not supported, the content and context are sufficient, or they're overused/misused and having to listen to/read through all the roles would clutter up the content. <dl> lists with their <dt> <dd> elements are fine to use but screen readers rarely convey their roles. a11ysupport.io is not comprehensive and its volunteer data is not kept current but it still offers a sense of the divide between what's theoretically possible and what actually happens. https://a11ysupport.io/tech/html/dt_element https://a11ysupport.io/tech/html/dt_element

by mk12 2y ago

edent 2y ago

If you use `<i lang="la">sic transit gloria mundi</la>` then your screen reader should read the text in a Latin accent rather than munging whatever your default language is. As for the rest, they look the same now. But HTML is supposed to be future proof. Suppose, in the future, people prefer emphasised text to slant backwards, definitions to hover holographically, and cites to render directly to your neural link. Or, suppose right now you want to screen-scrape a page and get all the definitions. That's why I use semantic HTML.

troupo 2y ago

Screen readers should read those tags differently. em is emphasis, cite is citation etc.

extra88 2y ago
In theory they could, in practice they don't because almost nobody writing those elements pays attention to that level of detail or use them solely for a visual styling effect that has no bearing on understanding the meaning of the content.

kaoD 2y ago

The semantics are indeed different in screen readers and the elements will be announced differently and behave differently in the accessibility tree (by virtue of having ARIA roles like e.g. "term"[0] or "definition"[1]). Note that ARIA roles change drastically how elements are announced -- a screen reader would take forever to announce elements if they were not scoped by their role because it would have to announce what an item is not (e.g. if it's unchecked, which is announced for "checkbox" roles, which can be and often are <span>s). ARIA roles make a bunch of ARIA attributes hidden (or, conversely, shown) in the accessibility tree. It also gives context to additional ARIA attributes like aria-details[2] because now the screen reader knows that the details are the definition or whatever, and will announce those appropriately. Using semantic elements allows you to have the proper ARIA roles (and thus the accessibility tree be properly scoped) without thinking too much or polluting your DOM tree with aria-* attributes. There are also some other semantic-related benefits. E.g. from <dfn>'s MDN page[1] "if you include an id attribute on the <dfn> element, you can then link to it using <a> elements. Such links should be uses of the term, with the intent being that the reader can quickly navigate to the term's definition if they're not already aware of it, by clicking on the term's link." I know you can already id-link to a simple <span>, but the thing is the screen reader would be able to announce that the link is to a definition so the user is already aware of the link purpose even before clicking it (unsure if any do this, but they could). Or maybe the user agent could build up a list of definitions automatically and allow you to quickly look up them, even if they are not explicitly linked. Most importantly: you might think that sighted users cannot tell the difference between the default styling of all those elements, but they often can by virtue of what they are visually surrounded with and other contextual clues that are not available while using a screen reader. E.g. `<cite>` is often surrounded by other visual cues that might not be obvious to screen reader users which have a very local and narrow contextual scope (you can only hear elements one at a time, while visual users can see a bunch of context at a glance). Also, sighted navigation is much faster than navigating via keyboard+narration so the additional affordances really help non-sighted users. Imagine having to wait for a whole paragraph to be narrated to get to some textual clue near the end of the paragraph, or even further down the content... or worse, above the current content (think an <h2>Definitions</h2> for example) which will normally not get visited while you navigate piecewise. It's very hard (impossible?) to read/navigate diagonally with a screen reader. We get so much instant info visually that we take for granted and it's just not there for screen reader users. Lastly, you can style those differently in CSS even if the default user agent stylesheet does not. E.g., by giving <dfns> a dashed underline or a different mouse cursor. I know you can do that by manually annotating <span>s with classes but the thing is... you don't need to. So you can give additional visual affordances to sighted, but also to cognitively-impaired or partially-blind users too. [0] https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/term_role https://developer.mozilla.org/en-US/docs/Web/Accessibility/A... [1] https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/definition_role https://developer.mozilla.org/en-US/docs/Web/Accessibility/A... [2] https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-details https://developer.mozilla.org/en-US/docs/Web/Accessibility/A... [3] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dfn https://developer.mozilla.org/en-US/docs/Web/HTML/Element/df...

extra88 2y ago
There are many roles that exist that are not actually conveyed by screen readers. Either they're obscure and so seldom used that no one cares if the role is not supported, the content and context are sufficient, or they're overused/misused and having to listen to/read through all the roles would clutter up the content. <dl> lists with their <dt> <dd> elements are fine to use but screen readers rarely convey their roles. a11ysupport.io is not comprehensive and its volunteer data is not kept current but it still offers a sense of the divide between what's theoretically possible and what actually happens. https://a11ysupport.io/tech/html/dt_element https://a11ysupport.io/tech/html/dt_element