Accessibility notes on the www.spiegel.de relaunch

I really like relaunches of websites. Not only as part of my job, of course, but also when teams or stakeholders behind big projects like websites of newspapers, TV station or governments decide to roll out a new and updated version. Often enough some time has passed between two relaunches, so sometimes not only the expectations of the visitors, but also the landscape of web technology have changed. So it's very exciting to open dev tools, and look into the new code. Have they used a specific CSS methodology? How is the headline structure? Do they use modern ways of lazy-loading? What's the performance of the new website?

Alas, these mini reviews – made out of curiosity and the drive to learn something new, especially regarding large scale projects – were a little bit frustrating in the past. Sometimes a website was relaunched and, without a doubt, more visually pleasing than the older one. But the code was just as bad and non-semantic and before. Or the website was (because of advertising, they say) still not responsive, although the concept and the technology was around for nearly a decade. But the biggest issue has often been the total lack of accessibility basics. One could literally feel how it was a non-priority during the relaunch phase.

Fortunately, this seems to change slowly but steadily. Last Wednesday, one of the biggest news websites in Germany, spiegel.de relaunched, and things went differently than usual:

• The dev team behind the relaunch wrote months before the actual relaunch a big medium article, even "spilling the beans" on the new design (note: German language, and as usual, Medium has severe accessibility issues).
• While the article didn't mention the topic of accessibility (I was snarky about this on my other twitter account), the actual relaunch last Wednesday incorporated a good baseline quality when it comes to accessibility. It's worth noting that it isn't perfect – but way better then the old version.

So when I looked into the code the following things came to my attention (have in mind that I didn't run a proper audit, of course):

• Focus styles. That is usually the first thing that gets removed "because the design department things these outlines are ugly". That is why technologies like the :focus-visible pseudo-class have emerged, matching only when the browser detects that the user is navigating via keyboard (or comparable devices). So focus styles that are visible on click are a thing of the past, if you just do it right (read: if you use :focus-visible, its polyfill or comparable solutions like whatinput). While spiegel.de uses none of the mentioned features or scripts directly they seem to have rolled with their own solution, preventing focus styles to "leak" when clicking. Regardless of the implementation details – discovering that was a nice surprise.

• Buttons are actually buttons – and labeled! The "clickable div" is such a classic anti-pattern when you deal with or teach accessibility, then it's hard to not become a cynic, and not to expect them at websites that did not really care about accessibility in the past. All the better, that – at first glance – every interaction control that should be a button, actually is a <button>. Furthermore, that the developers didn't stop there but made sure that every button (even the icon-button ones) have an accessible name. Very nice. Unfortunately, not a given.

• Landmark regions are present, most of them labeled. The next cause for giving a thumbs-up (carefully) was that there are now landmark regions like <main>, <nav>, <aside>, <header> and <footer> available, at least on the start page. What's a little irritating is that only some of them are labeled (That's good for example when it comes to telling certain navigation areas apart). Unfortunately, some <nav> regions are missing labels, especially the one containing the breadcrumb widget on a single article page. I don't know this for sure, obviously, but I bet this has to do with some internal politics and departments. Nevertheless, I guess, in big scale content management systems it is a little bit easier to add an aria-label attribute, then to change the element. It is therefore not unlikely that this will be corrected in the future.

• A headline's kicker and the part "with the bigger font" are a consolidated <hX> element. Since there is no equivalent for a "kicker" (that's a kind of headline above the actual headline, giving context) in HTML developers often chose workarounds for it, that either makes the kicker line a proper headline by itself, or a span or paragraph that is not really programmatically connected with the actual headline. It's good to see spiegel.de went for a different solutions: unifying kicker and the visually bigger part in one element, and apply the different styling with <span>s. More or less like this:

    <h2>
        <span class="kicker">I'm above</span>
        <span class="headline">I'm the visually enhanced part</span>
    </h2>

• SVGs have a role="img" and are labeled properly. Especially on big websites, that aren't enforced by law to be accessible, it is both rare and delightful to stumble over (nearly) perfectly accessible SVG. The following (edited and commented) snippet shows the logo vector image:

    <a href="[https://www.spiegel.de/](https://www.spiegel.de/)" title="DER SPIEGEL" aria-label="DER SPIEGEL">
    ...
    <span class="block leading-none lg:hidden md:hidden">
        // 🏹 Notice how aria-labelledby references the id of the title!
        <svg aria-labelledby="title-ca860bec-0519-44f4-b76a-6ffe19e7cb5b"
            width="137" height="18" viewBox="0 0 137 18" fill="none"
            xmlns="[http://www.w3.org/2000/svg](http://www.w3.org/2000/svg)" role="img"><title
        id="**title-ca860bec-0519-44f4-b76a-6ffe19e7cb5b**">Der Spiegel</title><path d="...." fill="#fff"></path></svg>
    </span>
    [.](http://www.w3.org/2000/svg)..
    </a>

  "Not perfect" in that regard that the accessible name sometimes still has text starting "Icon:" or "Image:" (role="img" does that for you!), and that focusable="false" is missing to prevent a redundant tab stop in Internet Explorer. But apart from that – good work.

Conclusion: There are still errors, in some cases even fundamental ones (like missing alt texts) or widgets that could be improved (disclosure widgets should work with aria-expanded on the triggering button). Nevertheless: I am happy about the improvements. Inclusive design is an increasingly relevant topic, and it's always nice to be able to give references to one's own customers customers, being able to name larger sites (which they may even visit daily) having recognized the importance of accessibility!