As we’re entering the last stages of 2021, I think it’s time to add a little wishlist for the future of the web. Since accessibility is getting more (deserved) notice. I thought that this year might be a good time for an HTML wishlist.
Accessibility starts with good HTML
Forget about ARIA and roles for a moment, The best accessibility is achieved without specific shenanigans and a strong foundation in your HTML. Too many times we’re “fixing” things for accessibility while in reality, it’s not the hardest thing to do. Perfection might be hard, I can agree to that, but a basis for an accessible web, shouldn’t be.
We get too many comments about this such as:
- Our CMS or framework won’t let us output HTML that way
- The client doesn’t care anyway
- It just takes too much time
- I can’t convince my boss
When you get your basic HTML right from the start, it shouldn’t take too much time and if your CMS or framework won’t let you output the HTML the way you want, you might want to start thinking of using something else, because in the end: it all comes back to the basic building blocks.
So why create more HTML tags?
The ideas I gained over the years are mainly based on a course that I followed at the AnySurfer office. They help to spread the word about accessibility, give courses and “Anysurfer labels”. They even test your website for a price. Belgium doesn’t score well in the accessibility field, there is a lot of room for improvement, but times are changing.
When following the course there is one thing that intrigued me. Screen Readers are smarter than you might think. They can give a list with “all H2 tags on the page” or “all the links on this page” by using the rotor function. Which made me think on how we can improve accessibility for people using this kind of aid. I strongly believe that if we start adding useful new HTML tags, a good practice in accessibility could be more consistent because they are easy to learn and maintain. Creating good accessibility isn’t that hard, but it would be better if it’s easy.
Also, never forget the first rule of ARIA
If you can use a native HTML element [HTML51] or attribute with the semantics and behaviour you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.
Before I make this list, I want to point out that this is purely about some ideas that I heard, or read online and that they're purely fictional (for now). I will include information on where I found the idea if applicable. They are by no means a “top 5”, just five in total.
1 <banner> tag for banner USP’s & promotions
Especially with the pandemic, webshops started to rise as the skyline of New York in 1900. Imagine a native html tag for the
role=”banner” to add promotions on a webshop. A rotor might show “all the banners on this page” and get results such as “buy 2, get one for free” on the current product page.
<banner> Buy two products, get one for free! </banner> <!-- or maybe the following? as it might be interesting to combine images and text inside the tag --> <banner aria-labelledby="banner-title"> <h3 id="banner-title">Buy two products, get one for free!</h3> <img src="some-image.jpg" alt="Promobanner: Buy two products, get one for free" /> </banner>
2 <price> tag
Staying in the webshop story, this one could be handy as well. Especially for the way aiding devices would pronounce prices. However, I do think this would need a bit of extra, maybe a type attribute to define what kind of price we’re printing out such as “discount” or “total”. It could reduce the amount of hidden texts. We might even benefit from a currency attribute to specify that as well. One side note here is that I do feel there is a bit of danger involved in this when it comes to scamming people. We have “price tags“ in stores, now let’s add them to HTML? It kind of makes sense to me.
<!-- some wild ideas here, but in this idea the price should only contain numbers --> <price currency="euro">20,00</price> -<price currency="euro" type="discount">5,00</price> +<price currency="euro" type="addition">3,00</price> <price currency="euro" type="total">18,00</price>
3 <alert> tag
Truth be told, this might be my favourite of this list and let me tell you why. It seems very easy to implement in new websites or to add on older websites. This one would be great for websites who already have a bad score. Many times, forms and especially error handling can be frustrating for users with a reader. They notice something went wrong, but it’s hard to tell where the problem is located, or which field gave an error. It’s not the hardest thing to get right for those users, but if there was a way that they could “view all alerts on this page” and then read which field gave an error (and why). It could make the frustrating journey a bit better.
alert(); I could settle for a
<alert type="error"> <p>There was an error submitting the form</p> <ul> <li>Email field has invalid characters</li> </ul> </alert> <alert type="success"> Product xxxx was added in your basket. </alert>
4 <search> tag
This one caused a bit of commotion on the web this year, some liked it, others were against it. But I personally think Sara Soueidan has some excellent points when it comes to adding the search tag as a sectioning element. I think that many people use the search first, whether it be in documentation or webshops. The search is often a go-to place when a user gets lost as well and could be a savior for keeping people on your website.
It could be used for the default search forms with or without options, but maybe we could even take it a step further for when it comes to filtering a large catalog.
5 <chart> tag
Charts are always hard for accessibility, mostly because they are a visual representation of data. When the “visual” gets removed from the representation, there isn’t much left.
There are many ways we can tackle this by adding Screen Reader only text or captions, but having a built-in feature would be a very nice to have. I see this as an alternative to the
<figure> element where the
<figcaption> isn’t shown by default and contains a descriptive representation of the chart.
<chart> <!-- some canvas or other html that creates the visual representation --> <chartcaption> A description of the chart, could also be a <table></table> element maybe? Is visually hidden by default. </chartcaption> </chart>
It’s time for HTML to rise again
It’s been 7 years since HTML5 was released and I think it’s about time the language gets a bit of extra love. We’re writing ARIA helpers all the time and sometimes end up doing more damage than good. These are just some wild ideas and I’m far from an expert when it comes to the legacy of browsers.
It’s important that we “don’t break the web” by adding new tags that might have some history behind them in older browsers. But that concludes my wishlist, who knows, maybe Santa will bring some of those presents in 2022.