Using address in HTML won’t be problematic for much longer
There’s a bug in Safari (WebKit). It adds an implicit role of
contentinfo to any instance of an
<address> element. This means that VoiceOver reads “content information” for an
<address>, which is the landmark role normally associated with the main
<footer> of a website.
So if your website has a footer (it almost certainly does!) and an
<address> somewhere, this is going to be confusing for screen reader users. There should only be one
contentinfo landmark on a webpage, so a second will make people wonder what’s going on. And when they navigate to the
<address>, they’ll be given an address, rather than the full content they’d usually expect from a footer. Not a great experience.
Scott O’Hara has written about the problem of
<address> having the implicit
role="contentinfo", and even proposed a fix. If we override the built-in semantics by adding
role="presentation" to the
<address> element, VoiceOver doesn’t treat an
<address> as content information.
I did this to the address in my website’s footer, but as Scott points out in his article, it’s a hack.
But there’s good news! The WebKit team were listening, have recognised this as a bug, and the fix was made last month. I’ve tested this with the most recent version of Safari Technology Preview (release 110) and the implicit
<address> is gone!
So I’ll soon be removing
role="group" from my website’s addresses. I just need to wait for usage of pre-fix versions of Safari to drop off a bit, but as it’s an ‘evergreen’ browser, I don’t see that taking too long.