Some CSS libraries suggest not using HTML semantics and just use CSS. So H1 isn't used, rather SPAN with corresponding CSS to make it look like an H1.
I guess this makes things hard for a screen reader since HTML isn't saying what's what anymore.
I guess this makes things hard for a screen reader since HTML isn't saying what's what anymore.
At a deeper level, you have to appreciate that browsers are built around the “separation of concerns”:
- html for content
- css for layout, look and feel
- javascript for behaviour
The front-end community has some loud voices at the moment telling us that these are the wrong separations; that the styles for a component go hand-in-hand with their behaviour and semantics. I’m not getting into that debate here. But I do want to say that this newer interpretation of the “concerns” applies to code you write for your application, and is (currently) not how browsers are constructed. It may make more sense for you as a web application developer to structure your code by colocating your layout and behaviour solutions in one file, and in that way you’re more likely to use <div> and <span> over more expressive elements. But that’s not what your users’ browsers are expecting you to do. They’re built around the older separation of concerns. And they’re built to amplify the strengths of the three languages they interpret. So that <div> tells the browser “i want you to treat this content just the same as you treat any other content”, where a <h1> tells the browser “add this content to your document outline, expose it as a section heading to the accessibility tree” as well as reminding it to apply the default styles.
Attack the problem (unwanted styles) at the right level of separation (at the styles level).