Follow up on my spiegel.de notes: Interview with Daniel Schulz from SPIEGEL Tech Lab

Following the publication of my "Accessibility notes on the www.spiegel.de relaunch", it was a little bit by chance, and a little bit due to Twitter that I was able to contact a member of the spiegel.de NextGen team. Though Daniel Schulz came into the project relatively late he supported the team regarding the accessibility aspects of the relaunch. I jumped at the opportunity to ask him my now (somehow traditional) seven questions:

Could you tell me a little bit about your background?

Hi, I’m Daniel. I’ve been a frontend developer with SPIEGEL Tech Lab for about half a year now, which means I’ve come to work on the Spiegel NextGen project in its later development stages. The design was finished and most of the structural work was already done at that point.

What was your exact role in the relaunch process? 

I was (and still am) working on the frontend of spiegel.de. There are five other developers dedicated to that part of the project, with more people involved in QA, backend, infrastructure, apps and project management, of course. We strive to have as low hierarchies as possible, so there’s not really too much to say regarding my role. 

When you joined the NextGen team, what accessibility basics did you find?

Regarding the code base and team knowledge, at that time? Accessibility was just an afterthought at that point. We had <div>-Buttons, unlabeled form fields, invisible tab stops, no landmarks… the usual suspects. And I get it. The team had a strong focus on engineering and web performance. Accessibility was simply not included in our definition of done. However with our performance focus, we decided against javascript-fueled content rendering, thus avoiding pitfalls like fragile page rendering. Luckily enough, the design templates were mostly WCAG compliant. Make Studio and our graphics team did a hell of a job there. 

Have you prioritized accessibility topics internally? If so, according to which aspects? 

We did and still do. We audited the site and identified a few main tasks: SVGs, focus styles, semantic HTML, aria labels, tab control. Those tasks were specified out and put into tickets. We expanded our definition of done to compliance in terms of keyboard and screenreader control. We argued that those things would be really nice to have for one of the most popular websites in Germany. With such a large and wide audience, we will definitely have users who rely on assistive technologies. So we made some time for those tickets and went to work.  

Did you train the team internally? If so, how? 

Not really. We had a team meeting where I explained what I worked on and what our QA was looking for now, and I talked about my research and progress in our Daily Standups. I was also always willing to answer any questions and help out. We never had a proper training though, and I don’t think that would have been necessary.  

What tools did you work with (especially regarding manual and automated accessibility testing)? 

We checked screen ready compability with Apples VoiceOver. Automated audits came from Lighthouse and Microsofts Accessibility Insights Chrome extension. Especially the latter proved to be very valuable.  

Have you worked with external experts? 

No. I picked up a lot from previous colleagues and read about it. I can absolutely recommend Heydon Pickerings Books. I do think an external Audit would have helped, though.

Thanks, Daniel, for your work on moving the needle regarding a more inclusive web! It was amazing to gain a little insight into the small but growing processes around accessibility as a part of a complex and highly frequented project like spiegel.de.If you are interested in past "seven questions" regarding accessibility evangelists in teams, their strategy, methods, backgrounds and stories:

• Michael Berger about his accessibility work on Basecamp
• Kitty Giraudel about their accessibility work on n26