Lost in Translation

A frontend developer’s job is to look at a design, interpret it, and translate it to HTML and CSS. Unfortunately, information often gets lost in translation because we rely too much on visual aspects of a design, rather than its semantic meaning.

In his talk, Manuel Matuzović uncovers the invisible patterns we should recognise in a design, and how they affect accessibility.

Transcription

[Music]

[Audience applause]

Manuel Matuzovic: Thanks a lot, Marc, and also thank you so much for having me. It’s such an honor and pleasure to be here.

It’s an honor because I’m on stage at one of the best Web design and Web development and design conferences in the world. And it’s a pleasure because this is my first in-person conference since 2019, and I’m really glad that I get to share this moment here with you in Dusseldorf.

[Audience applause and cheers]

Manuel: My name is Manuel Matuzovic. I’m a front-end developer from Vienna and, by day, I work for the City of Vienna and, by night, I work as an accessibility auditor and consultant.

When I do consulting, I work with all kinds of different companies -- smaller companies, larger companies, institutions, universities -- and they all have all kinds of different stacks. Some of their sites run PHP or on Python or on asb.net, whatever that is, and they have all kinds of different content management systems like WordPress, Kirby, or Craft. Also, some of them, of course, use JavaScript frameworks or libraries like Angular or React.

When my first client with a React stack approached me and asked me if I wanted to work with them to help them with their accessibility on the website, I was hesitant at first because I didn’t know if I would be able to help them with their questions because, at that time, I didn’t know anything about React. But I thought about it, and then I just went for it, and I said, “Yes, let’s do it,” because he was a nice guy, and I also wanted to really work on that project.

I thought, “If I put myself just under enough pressure, I would be able to learn all those things in React in order to help them with their accessibility. A really nice putting yourself under pressure is to sign up for a React conference in Finland, get accepted, and give a talk in front of 500 React developers.

[Audience laughs]

Manuel: On screen, you can see me speaking at React Finland in Helsinki in 2019. My arms are wide open. You can just feel my confidence. And behind me is the beautiful React logo.

At some point, the workshop came, and I worked with the clients. As it turns out, I didn’t talk too much about React. I mean I talked about some things, but I mostly talked about HTML.

Most of the questions and most of the issues were related to HTML. This is something that all of my clients have in common no matter the stack. Most of the questions and most of the issues are related to HTML.

It’s funny because I already kind of knew that but just didn’t consider it or didn’t think about it because when I started to specialize in Web accessibility in 2016, I read all the articles, everything there was. I read articles, I watched talks, I watched videos on YouTube, I took courses, just anything that I could get in order to learn how to build accessible websites.

After two years, I shared my first insights on A List Apart. I wrote a post called “My Accessibility Journey: What I’ve Learned So Far,” and I shared these learnings and insights. One of them was a solid knowledge of HTML solves a lot of problems.

I already knew that in 2018, but somehow I just thought this doesn’t apply to my clients. This doesn’t apply to large companies with people who create products, visited by thousands and thousands of people every day. I thought this only applies to - I don’t know - beginners (like me at the time).

When I thought about the early days of me getting into Web accessibility, I also remembered how I started following Web accessibility experts on Twitter. I was surprised that they mostly shared basics, HTML basics, on Twitter. They did it over and over again, year after year; they shared the same basics.

I was just wondering, when do you start to share the complicated accessibility stuff, the scary accessibility stuff, the stuff that I was so scared for so many years that I just thought, “I’m too scared, so I’m just going to ignore that. I don’t have to build accessible websites”? When do you start to share that stuff? And they rarely do.

Now, many years later, I see myself do the same things. I keep repeating the same basics over and over again, year after year.

My friend Max Bock once jokingly said that it’s fascinating how I was able to build a whole career based on a single HTML element, the button element.

[Audience laughs]

Manuel: Because I keep talking so much about this element. You can see a photo of me my friend Mathias Ott took yesterday, and I’m holding a poster that says, “A div is not a button.”

I even have a website called The Button Cheat Sheet. I kind of created it as a joke, but it got shared so much because it was a valuable resource. I’m sharing how to create a good button and how not to create a button - because a div is not a button.

And I’m wondering why. Why is it that we are not good at HTML? Why is it that the quality of most websites, in terms of HTML markup is just so bad? And this, after this language existing for almost 30 years.

You can see the very first publicly available HTML document published by Tim Berners-Lee 29 years ago. I was thinking, how is it possible that after almost 30 years of hearing just how simple and how easy HTML is that we are still so, so bad at writing HTML?

So, one day, I had some time, and I was sitting in my hotel room. You can see a photo of Bill Murray in the movie Lost in Translation. You can see him sitting on the bed of his hotel room looking depressed.

I was sitting in my hotel room, and I was thinking about HTML, you know, the things you do in a hotel room.

[Audience laughs]

Manuel: I was thinking about the HTML, and I was trying to come up with reasons why the quality of most websites is so, so bad, at least in terms of HTML. I came up with some things, and I want to share them with you today.

The very first thing is we are not as good at writing HTML as we think we are. I know what you’re thinking. “I am good at writing HTML!” And I’m sure that some of you are. But the majority of us is really, really bad at writing HTML.

You can see a main element on the screen and, in this main element, is a section. Nested in the section is a header, nested a section, a section, an article, a section, a div, an article, and another section nested in this element.

I can say that we are bad at writing HTML because I’m an accessibility auditor. I get paid to assess the quality of documents. I look at a lot of code others have written.

I also have a website called htmhell.dev where we take bad practices that we find on production websites. We put them on the website. Of course, we remove any traces to the people who built it. We don’t want to blame or shame anyone. We explain what’s bad about the pattern, and we provide better solutions.

I also have this really shitty habit of not being able to surf the Web. I don’t enjoy surfing the Web. I just can’t surf the Web properly because, when I visit a website, I have to open dev tools, and I just have to inspect that button and see if it’s a div or a button.

[Audience laughs]

Manuel: I don’t enjoy surfing the Web.

And I’m sure that most of you are good at writing HTML, the language, the syntax. I’m sure that most of you understand that and know that.

I’m also a teacher. I teach for more than 12 years and, usually, it takes about two hours for me to teach beginners how to write HTML. It takes two hours for them to understand that there is a start tag, that there is an end tag, or there might not be an end tag. That you can put content between the start tag and the end tag. And that you might want to add an attribute and a value to a start tag.

[Audience laughs]

Manuel: It takes about two hours for them to understand that. After two hours, they’re able to create a basic document and write the structure.

But that’s not what I’m talking about. HTML is not just about the language, about the syntax. It’s way more than that. It’s about semantics. Yes, semantics! Semantics are important.

But do you know why they’re important? Do you know why it’s important to use this element or that element? Did you know all the things that Leonie told us yesterday?

Also, how many HTML elements do you know? How many are there? Don’t shout it out, but just try to think of a number. 20? 50? 70? 100? 200?

Some developers might say there are only two elements, and you only need two elements.

[Audience laughs and applause]

Manuel: And I’ve seen websites that only use these two elements. But of course, there are way more than that. If I counted correctly, there are 113 elements in HTML.

How many of them do you know? Good question. Paul Foster asked this question, and he created the HTML text memory test. IT’s a super fun game. It’s super simple.

It consists of an input field, a button, a counter, and a list. You add a tag name in the input field. If it exists, it will be added to the list and the counter goes down. It’s a super fun game.

It’s highly addictive, so please don’t play it now because I have really important things to say to you and I want you to listen to me. And please don’t play during the other talks because the other speakers have also important things to say. But definitely play it afterward.

I would say, if you remember 50 tags, you’re good. If you remember 70, you’re really good. But there are 113.

For Paul, there are 115 because he also included the SVG and the math element - just as a side note.

Okay. That’s the first reason we’re not as good at writing HTML as we think we are.

The next reason is designers know too little about HTML. Now, don’t get me wrong. I really don’t want to put this on designers and blame designers. But I just believe that a basic knowledge of the languages your designs will be translated to, so HTML and CSS, can be really helpful for you as a designer professionally because you get better at what you do.

It can be good for you, for your team, for communication with developers because it’s just easier to communicate if you know more than just one language or the language the other person is speaking. Ultimately, it’s better for your product and your users, and Web development is about users.

But admittedly, this is just one reason. It’s not the most important or the most significant reason. It’s just one.

I can imagine that some of you maybe don’t like the things that I just said. And if you’re not already typing, I would say now is a good time to log onto Elon Musk’s website and complain about me and the things that I’m saying because the next reason is some people just don’t care. Some people just don’t give a flying fuck about accessibility and users.

Here’s an example. This is the main navigation of the website of a kind of well-known front-end developer -- sorry, JavaScript developer -- no, JavaScript engineer. This is the navigation of his website, and it’s a div with a class of nav. In this div, there is another div wrapped, and the two links are divs, so not A elements but links with JavaScript events.

This is their main navigation, and this is someone who has more than 25,000 followers on Twitter, someone who gives talks, someone who writes articles, someone who is in the industry for many years, and he just can’t tell me that they don’t know that the A element exists or the nav elements. And you can’t tell me that they don’t know what semantics are and how important it is and how important accessibility is. This is just not possible. They don’t care.

To be fair, this is their old navigation. They changed it recently. This is how it looks now, so they got rid--

[Audience laughs]

Manuel: They got rid of one of the divs, but there’s still this div with the class nav. They now have links, which is great. Good for them. But, unfortunately, they wrapped the content in a button within the link.

But Leonie showed us yesterday how to do it. You use the nav element. If there are multiple nav elements on your website, you want to label them, for example using aria-label, and you want to structure the navigation using a list and proper links. And you can also highlight the current page using aria-current.

Okay. But I like to believe in the good in people, so I would say that most people do care and all of you care, and this is only a minority of us developers who don’t care.

Okay. The next reason: We put too much trust and hope in ARIA. When I audit a website, I have all kinds of different tools to assess the quality and the accessibility of a site. One of these tools can tell me how many ARIA attributes are in the page.

When I see that there are like 200 or 300 or 400 ARIA attributes on a single page, I know that I’m going to have a bad time because we developers don’t know how ARIA works. We are so, so bad at using ARIA, the whole specification and the attributes. We just don’t understand what it does.

This is not just something that I’m saying based on my experience. There’s data.

There is this nonprofit called WebAIM, and they have a website where they share all kinds of accessibility knowledge. They have a testing tool called WAVE, and they also create screen reader surveys, and they have this evaluation called the WebAIM One Million.

Since 2019, every year, they test the top one million websites. They run automated tests, and then they share what they found on these sites. One thing they found was homepages with ARIA present averaged 70% more detected errors than those without ARIA. Seventy percent more errors if there’s ARIA on the page.

[Audience laughs]

Manuel: It seems like developers are just randomly pouring ARIA attributes on websites and just hoping that magically somehow it turns into an accessible website.

On screen is a photo of a chef with a comically huge bottle of oil and he’s pouring it into a salad, and I’ve labeled the chef a full stack developer, the bottle ARIA, and the salad “accessible website.”

It’s fine to use ARIA. Use it, but please only use it if you understand what you are doing and if you are aware of the consequences.

Leonie gave a fantastic example yesterday where she used the menu bar role, and she told you how she wouldn’t be able to use it if it wasn’t for the extra stuff that you had to add, the extra keyboard events, and so on.

It’s again, not just me who is telling you to not use ARIA if you don’t understand it. It’s in the spec. The spec also has these five rules of ARIA, and they are saying, “If you can use a native HTML element or attribute of the semantics and behavior you require already built-in, instead of repurposing an element and adding an ARIA role, state, or property to make it accessible, then do so.”

Wow, that was a heavy sentence.

In other words, no ARIA is better than bad ARIA. If you don’t know what you are doing, just get rid of the stuff and use native HTML.

Okay. Eventually, I had to leave the hotel room because shit was getting expensive. I was there for weeks thinking about the HTML.

[Audience laughs]

Manuel: So, I left the hotel room, but I left it with a bad feeling. It kind of didn’t feel right. It was like, okay, yeah, I mean it’s true; we suck at writing HTML, and some of us don’t care. But there must be more to it.

So, I went back to the hotel room sometime later, and I was looking depressed and sitting on my bed. And I was thinking about HTML some more. And I tried to find more reasons.

At some point, I figured that, you know, lack of knowledge is not the only cause. Also, the lack of caring, of empathy is not the only cause. There must be something fundamentally wrong with the way we approach front-end development, with the way we build websites.

I only had this very fuzzy theory. There wasn’t much substance, so I did some research.

I looked again at the WebAIM One Million report. On this report, they also list the most common issues that they found in these one million websites.

There are six of them. They are low contrast text on more than 83% of websites, missing alternative text for images on more than 55% of websites, empty links on more than 50% of websites, missing labels for input fields on more than 46% of websites, empty buttons on more than 27%, and missing document language on more than 22% of websites.

I was looking at that and trying to understand it, try to get a feeling for the types of issues, and I did some more research. This report was published a few weeks ago, and some developers responded to that.

For example, my friend Hidde, he did a piece. He wrote “Common Accessibility Issues that You Can Fix Today,” and he goes through this list of types of errors, and he explains how to fix them and where you can find tools and all the things that you should and you could do to avoid these things.

Or there’s an article by Christian Heilmann that is titled “One million broken web sites - and a way to prevent that,” and he goes into how you can use dev tools in Edge in order to fix these things and to debug them.

Both posts are really great, so definitely check them out. I will share the slides with you later. Read these. It’s really interesting.

But the thing is, what they’re doing is that they’re repeating the same basics over and over again year after year, and they’re fighting the symptoms. They’re not fighting the cause.

This is what we all do. We are constantly fighting the symptoms and not the cause.

The thing is it’s hard to pinpoint the cause. I’m not sure if there’s only one cause or if there are many reasons why we suck so much at HTML.

This is why I’m here. I’m just thinking. I’m just trying to sort the thoughts in my head, and I’m just trying to come up with a reason. I’m not sure if I’m able to do it today, but you know I’m just sharing some things.

Okay, so I looked again at the list of these most common issues. I just ran again through this list, and I was like, “Okay, low contrast text.” There are literally hundreds of tools that you can use in order to test that stuff. There are plugins for Sketch and Figma. There’s built-in stuff in your browser, in dev tools. There are applications. There are websites. That stuff is avoidable.

Missing alternative text: How often do you want to hear that you just used the alt attribute on an image? It has to be there all the time. If the content matters, you explain the image. If it doesn’t matter, leave it empty. But just put an attribute there.

Empty links: I mean just add text.

Missing form input labels: From the top of my head, I can come up with four different ways of labeling inputs.

Empty buttons: The same as links.

Missing document language: I mean you just put a language attribute on your documents.

While I was thinking that, especially when I’m saying that, I was like, “Whoa! Hey. Hey. Hey. Dude, that’s pretty toxic behavior you’re showing right now. You are standing here with your 22 years of experience writing HTML, 14 years of experience building professional websites, and 6 years specializing in accessibility, and you are telling us these things are easy and simple? That sucks, Manuel. That’s not nice.”

I’m right. That’s not nice. And I’m wrong about these things, but I kept hearing for all my professional life how simple and how easy HTML is. But it’s not.

We are wrongfully downplaying the complexity of HTML due to the simplicity of its syntax. What I mean by that is that it’s pretty easy to learn the language for most people, but it’s really hard to create the good document, a well-structured HTML document.

The thing is there is more to HTML than just tags and attributes. HTML is about structuring a document, creating semantic relations between elements and parts of your document. It’s about labeling content. It’s about describing content. It’s about describing state. It’s about describing page changes. It’s super complex stuff.

Again, I was looking at the list, and I tried to find something that they have in common. I found one thing that five of these six things have in common. I haven’t included low contrast because this type of issue is a bit different.

The other five, they have one thing in common, and that’s that they’re all related to something that isn’t visible in a design, but it should be in a document. When you look at a design, you should see those things even though they’re not visible.

This brings me to the next reason. Accessibility issues don’t just come from what’s visible in a design but from what’s not visible. There is a lot of stuff that should be in a document that we don’t see but we should see it.

Let me try to explain what I mean by that. Let’s look at the process of writing HTML. Let’s talk about the process from idea to product, from design to code.

Usually, how it work is like this. We first get a design, so we look at the design. I call this the exploration phase. We look at the design, and we try to get a feeling for the design.

We look at the colors and how they harmonize. We look at the type, the different type faces and how they work together. We look at font sizes, line heights. We look at the fine nuances of a design like shadows and lines and some playful little things that a designer put in there, and we try to get a feeling for the visual hierarchy and how the whole thing works visually.

Once we have that, we try to understand what all the things are supposed to do and what they mean and how they work. We try to get an understanding of what we see. We interpret what we see in a design and try to get an understanding.

Then we take that, and then we start programming HTML. We take the things that we understood, the thing that we interpreted, we saw in the design, and we translate that to code, to HTML.

When we take the first two things that are said -- we don’t know enough about HTML and we don’t care enough -- then these are things that happen between the understanding and the development phase. If I interpret the design and I don’t know enough about the language, it’s really hard to create a good translation.

Here’s another example. My parents are from Bosnia. They were born in Bosnia. I’m born in Austria. I speak Croatian, Bosnian, Serbian, but it doesn’t matter (if you ask me). [Laughter] It’s pretty much the same language.

I speak it. I’ve learned it. I’ve forgotten most of it because, you know, most of my friends are Austrian and, unfortunately, forgot the language.

If you give me a text in Croatian, I will be able to create the translation, but it will be a bad translation because my vocabulary is limited and I also don’t know certain phrases and idioms and places and names, so there will be a translation but a bad one.

This is similar in HTML. If you don’t know about all the different semantic elements and the attributes, you won’t be able to create a good translation.

You can understand and interpret as much as you want, but if you don’t care, then the translation will also be bad.

Now, if we take the last thing that I said that there are things in a design that are not visible but they should be in a document, this is something that happens in the phase between exploration and understanding.

If we look at the design, and there is something and we don’t see it, it might happen that this thing might... wait for it... get lost in translation.

[Audience laughs]

Manuel: Yeah. [Laughter] And these things have consequences... critical, serious consequences. If you don’t build HTML documents properly, users might not be able to get a basic understanding of what your website is about and what they can do on the site.

Why are they here? What can they do on the thing that you built? They might not be able to get a good overview of all the items in the page. They might not be able to orientate, to understand where they are in the whole page or in one of the flows of your website.

They might not be able to get the information that they need. They might not be informed of changes like DOM changes in your page. And they might not be able to navigate.

Okay. Now I want to try an exercise with you. I have a friend -- I mentioned him earlier -- Max Bock, and he designed the website.

He asked me, “I’m an entrepreneur. I’m an engineer. I’m so busy. I don’t have time to turn this design into HTML. Can you please help me, and can you please ask the Beyond Tellerrand crowd to help you?”

Would you help me turn some of the designs in HTML?

[Audience cheers]

Manuel: Okay. Let’s do it.

Let’s first look at the design. This is the design in Figma. It could be in Sketch or XD or any other application. I’ve worked with InDesign, Word. [Laughter]

[Audience laughs]

Manuel: But this is Figma. It doesn’t matter.

Let me just introduce you real quickly to the design. There is this introductory area at the very top of the page. You can see his portrait and his name. There are some links to other pages, and there is a circle with a paint roller.

Is this the right word? I’m not sure. A paint roller. Let’s call it a paint roller.

Then there is an intro area where he says, “Hello, my name is Max. I make websites.” Below that, you have an area with the featured posts, the eight featured posts, including a title and image.

Below that, you have another section with the most viewed posts, the four most viewed post and, below that, the four most commented posts. Then there is an area that finalizes the page with some secondary links, an area where he brags about his perfect Lighthouse score, and some more links.

Now, let’s start with this. Let’s look at this circle with the paint roller. What I want you to do now is to think of the markup. Try to imagine what kind of markup do you need to create that thing.

Don’t shout it out. Just think for yourself, but you have to be quick. We don’t have much time. We only have 17 minutes and 26 seconds left.

Look at that thing, and while you’re doing that, I’m going to show you some other implementations I’ve found on other websites for similar patterns. Maybe a quick explanation, so when you click that circle with the paint roller icon, a panel shows up. Then there are some buttons or radio buttons, and you can select a theme for the site. Then you can close the thing again.

Don’t worry about the panel. Just think about the circle and the icon and the fact that this opens this drawer with the different themes.

A very minimal solution that I see often is this, so just an SVG. It’s fine. You can do that. You can complete the visual task. You can create the circle and the icon, but the problem is that this circle and icon is an interactive element because you can click it. If you can click something, you should be able to do the same thing using a keyboard.

If I would use the tab key and I try to focus this thing, this SVG, nothing would happen because it’s not an interface element. We need an interactive element in order to make it keyboard accessible.

Let’s add a button.

[Audience laughs]

Manuel: I’ve wrapped the SVG in a div with the class button and it now looks like a beautiful button but, unfortunately, it’s only visually a button. Semantically, it’s just nothing. It’s just a div. It’s not interactive.

Okay. Let’s replace that with a proper button. Nice. Much, much better because now we have the visual and we also have an interactive element that’s accessible using the keyboard, and it also provides the correct role. We heard that yesterday. It would say button.

But we don’t know what kind of button this is because the label is missing, and every interactive element must have a label. Let me repeat that. Every interactive element must have a label. Input fields, radio button, checkboxes, an iframe, buttons, links: they all must have a label.

Let’s add one. We can use, for example, aria-label, so we put aria-label on the button. This labels the button. There is no visual label. But for screen reader users, now it says button change theme.

If you want to, you can use aria-hidden and put it on the SVG just to make sure that the SVG is not accessible to screen reader users because they don’t need this information. What they need is the knowledge that this is a button and that it has a label.

Now, this is pretty good for most, I would say, but it’s not perfect. There are also other ways of labeling. For example, you could just put text in the button.

This would be my favorite because this would work for everyone. It works for screen readers because there is a label, but it also works for sighted users because they see what this icon means and what it’s supposed to do.

But okay, of course, if the design demands it, you can also wrap this text in a span and use a screen reader only or visually hidden class to hide it visually while still maintaining accessibility. Unfortunately, there is no native way in HTML or CSS to do that, so you have to combine a bunch of different CSS properties to achieve that.

This is almost perfect, and one thing is missing. It’s the fact that the button controls the panel and the button is responsible for communicating to the user that they are in control of the panel.

We can do that by using the aria-expanded attribute. If you put aria-expanded on the button, it will announce something like “button change theme collapsed” because the panel is collapsed. And if you click it, you change the value of aria-expanded to true, and then it will say something like “button change theme not collapsed” or open. I don’t remember right now.

This is important. We can also add the aria-controls attribute and add some more semantics because this now creates a semantic relationship between the button and the panel it controls, and it provides additional ways to interact with this component. This doesn’t work with all screen readers and browsers, but you could add it. It would be a nice, additional feature.

Okay, so the perfect button for me is a focusable, interactive element (the button element, usually). It has an accessible name. It has a role of button. It might communicate state or something else.

Yesterday, we saw aria-pressed, for example, a different attribute. And it might also communicate a relationship if it makes sense.

This is how it looks like when the panel is open, so you can see the different themes, and you can select the theme. And you can also close it.

Let me just quickly talk about this one, the close button, because this is one of the most controversial patterns in all of Web design. Every other website that I look at does this pattern wrong because it’s so complicated.

We all now have the knowledge how to create a close button. We know it must be an interactive element, it must have a label, and it also must communicate the state. Sometimes, you see this, and this looks pretty okay, I would say.

The only thing I don’t like about this is the label. The label is X. I can imagine that, in English, you could probably say to X something, like to get rid of it, to close it, so this would work fine.

The problem here is now this is not an X. This is the icon for times, as in 2x2 or 3x4 or, in some screen readers, it might say multiplication sign, and this doesn’t make sense at all.

You see this on many, many websites. If you want to use it, fine. Just wrap it in a div. Use aria-hidden to exclude it from the accessibility tree and use a proper text label.

Okay. Nice. So, we have got that. Fine.

The next task for you is please look at the design and try to come up with how many headings there are on this page. Max asked me to create a document outline with you. How many headings do you see in this page? Some of you might see one heading. Others might see four. Maybe 20 headings.

Before I tell you how many headings I see, I quickly want to talk about wild bees.

One day, I was sitting on my couch, and I was watching TV. Usually, when I watch TV, I’m super passive. I’m just in this apathetic state. I’m just lying there aging slowly and not paying attention to what’s on TV.

But one day, there was this documentary about wild bees. And I remember, all of a sudden, I was wide awake. I was sitting on my couch looking at the TV, and I was saying, “Fuck me! How awesome are wild bees?! What’s going on?!”

[Audience laughs]

Manuel: How awesome are these creatures? And what are they doing to this snail shell? What’s happening? They are so awesome, and they are just so beautiful.

I absorbed every information they gave me about wild bees. I was just so amazed by these creatures.

The next day, I went to the next local bookstore, and I said, “Yo, you have to hook me up with the best book about wild bees. It’s important.”

The store clerk said, “Okay. No problem, bro. I’ve got you covered. Here it is.”

I was like, “Wow! This is a huge book!” and it is almost 500 pages. I’m really not sure if I want to buy that.

[Audience laughs]

Manuel: [Laughter] Then I wanted to figure out if this is the right book for me because I didn’t just want an index of all the bees in the world. I wanted to learn something about them, how they build the nests, how they communicate, how they interact with nature.

So, I opened to page three, and I looked at the index. This is in German, but it doesn’t matter. It’s just an index of all the chapters and subchapters of the book.

I was looking at it, and I was like, “Okay. There’s something about nest building. There’s something about the way they communicate. And there’s also an index of the most important bees in Europe.” I was like, “Okay. Yes. I’m going to buy that. That’s all the information I need.”

I didn’t have to open the book and browse through the book to learn if that was interesting to me. I just had to look at the index.

We can do the same thing on the Web using headings. If you create a nice heading structure, this is a really great way for sighted users to get an idea of how your page is structured. They don’t have to read everything. They can just browse through the page and look at the headings and get a feeling for how the page is structured and what the different sections are about.

Especially for screen reader users, this can be really helpful if you have a nice structure because, if you use a screen reader, you don’t just necessarily have to read all the content on the page. You have all kinds of different shortcuts to interact with the page, and one of them is to just list all the headings.

You can see here I have voiceover, running voiceover on MacOS, the built-in screen reader, and I’m listing all the headings. It’s just such a nice way to get an overview.

I’m on the Beyond Tellerrand website, and you can see there is an H1 and then the larger sections have H2s, and there are subsections with H3s. This is not the real document outline. I changed it in the dev tools.

Marc, we will have to talk about your headings data.

[Audience laughs]

Manuel: But it’s just such a--

[Audience applause]

Manuel: It’s just such a nice way to get an overview, and I can use the arrow keys and select the heading and jump directly into that chapter without having to interact with the rest of the page.

If you look at Max’s websites, if there’s just one heading, I mean it’s okay. Better than no heading. But there is structure on this page. There are some sections, some larger sections, so just a single heading wouldn’t be enough, if you ask me.

I see one H1. This is the main heading of the site. It describes the page.

Then I see an H2 for the featured posts. It’s not visible in the design, but it should be there. It makes sense to add it to the document.

I see one for the most viewed posts and one for the most commented posts.

This is now how it looks like. Let me just quickly play a video of me using voiceover on MacOS.

[Video played]

Screen reader: Heading level one: I make websites. Heading level two: featured posts. Heading level two: most viewed posts. Heading level two: most commented posts.

[Video ends]

Manuel: I’m sorry I messed up the recording. It’s not loud enough, but you can hear that it announces the level. Thank you. It announces the level of the heading and also the text within that heading.

If you create a sound document outline that uses meaningful labels to describe the sections properly, you don’t put just crap in your headings because of SEO or some other reason. Describe what each section is about.

Create a clean hierarchy, which means that you try to avoid skipping levels. You start with H1, and then you have H2. If you have subsections, you use H3, and so on.

You use enough, but not too many, headings because if everything is a heading, nothing is. Really think about the index and wild bees when you create your structure.

Okay. The next task Max wants us to solve is landmarks. He wants us to identify all the landmarks in this page, so all the important areas of this site. What I see is a header. Nice. I see a nav element. I see a main element and the footer.

Why is this important? Again, this is another way of navigating on the website. Screen reader users can list all the landmarks on the page and jump directly into them.

Just imagine how nice it is that you don’t have to interact with the header at all. You just open this shortcut. You just press the shortcut, and you jump directly into the main content. Super convenient.

[Video of screen reader reading through the page playing in the background]

Manuel: Yeah, so you can see that the banner landmark is the header. The navigation is the navigation. The main is the main element, and content information is the footer. You can directly jump into a landmark.

[Video ended]

Manuel: Okay, so the next task. Max told us to properly identify the natural language of this page. You can see it’s written in English, but Max, just like me, is also from Vienna, and he speaks German.

So, you might be tempted to define the natural language of his site as German because he speaks German. If you do that, it can have really serious and bad consequences.

If you have an HTML document, and you want to define the natural language of the site, you use the language attributes. If you set it to de, this means that it is short for Deutsch, which means German in German. [Laughter] Then, yeah, you identify the natural language of the page as German.

But if you set it to fr, it’s French, and en is English. This is really important to get that right. If Max’s website is written in English, you have to set the value of the language attribute to English.

This has all kinds of consequences. For example, screen readers. They might pick the voice the screen reader is using based on this attribute.

If we are on Max’s website, it’s written in English, the language attribute is set to German, a screen reader might look at the language attribute and say, “Hey, this is German, so I’m going to switch to the German voice,” and then it will read the content on the page and pronounce it in German. The screen reader will just sound like me, and you don’t want that.

[Audience laughs]

Manuel: You want someone who pronounces stuff properly in British English or American English or Scottish or Irish, whatever it is. But you don’t want him to pronounce it like I do.

The language attribute has an effect on hyphenation in CSS, on quotation marks, on translation, on spell checking, and on the default font selection for Chinese, Japanese, and Korean languages.

Here’s an example. Two years ago in Vienna, we went to the Pulse to vote for a new municipal government. We voted. Usually, at around 5:00 p.m., the largest news site in Austria publishes the first results.

They did that on this Sunday, and they categorized the results by district. In Vienna, we have 23 districts, and they all have names. They published the results and, shortly after, the first people started complaining about the names of the districts being wrong.

The developers looked at the site, and they were like, “I don’t know. It works on my machine. It’s fine.”

But then they investigated and, as it turns out, they were using Vue CLI, and Vue CLI comes with some boilerplate code and, by default, the language attribute is set to English. So, they published this German site written in German with the language attribute set to English, and the people complaining were users of Chrome, users who instructed Google Translate to automatically translate English content to German.

There were two districts. The 11th district is Simmering. Simmering is just a name in German or in Austria, but it means something in English, and so Google translated simmering to sieden because that’s the translation of “to simmer.”

The 23rd district is called Liesing. Again, just a name. What happened here is I think that Google Translate thought that it was a typo, that they meant to say lying, and that’s why they translated it to luge, which means to lie (in German).

[Audience laughs]

Manuel: You can see that the language attribute is really powerful and it has many consequences.

Okay. I only have two minutes so I’m approaching the end of my talk. There are, of course, many more things that are not visible in a design, but it should be in a document. But I don’t have enough time to show you more of these things.

Yes, I will wrap this up with some advice.

I’m not going to talk again about how to create buttons or lists and repeat the same basics over and over again year after year. I just did that, kind of, but I don’t want to do it again, so I will leave you with a bit of different advice.

Developers, prioritize HTML. When you work on a design, talk with your designer about what you see but also what the things are about that you see. Try to identify together with your designers, with your team, what the things in this design mean, what they do, and how they might change as users interact with those things.

This is important. Spend time working on the design in terms of semantics. When you start to develop, develop HTML first. Write all the HTML. Create a beautiful HTML document, and check if the site works in HTML.

Then you might even validate the HTML - if you know what that is.

[Audience laughs]

Manuel: Also, if you want to run an accessibility test just to make sure that the first draft is fine. When you’ve got all that, then you write CSS. If you are super fun, you might even add some JavaScript if you want to, if it makes sense for the user. If it doesn’t make sense, just write HTML and CSS. You’re fine.

Thank you. [Laughter]

[Audience applause and cheers]

Manuel: This is one of the most important things that I can advise developers and designers to learn who your users are and how they’re using the Web. The Web is more than just using a mouse and touch. There are so many different ways of using the Web.

When it clicked for me, this whole accessibility was, when I just watched the videos of how people use the Web, and if you know that, it’s much easier to create accessible products. If you know all these things, how they interact with sites, it’s much easier to consider all the things that you need in order to create a great product.

Please stop belittling HTML. It’s not simple. It’s not easy. It’s a complex, extensive language.

This one is also important. Universities, schools, teachers, course coordinators, prioritize HTML. Teach it properly. Don’t just teach the language as syntax. Teach semantics and accessibility. Tell your students why it’s important to create semantic HTML, why it’s important to use this element over that element, and what kind of difference it makes to put an attribute on an element.

If you don’t have the knowledge, get some budget and invite experts. Allow them to teach you how to teach HTML properly.

Rewrite your curriculums. These things don’t work. I’m especially talking to you, boot camp creators, people who promise beginners that they will turn them from zero to JavaScript or a front-end ninja in eight weeks.

I know that you believe that it’s important to know how to write JavaScript and React in order to get a job. I know that you believe that, but it’s more important to create accessible documents and allow people to use your documents.

You have to teach your students how to build accessible websites and allow people to access the content and allow people to participate in society. This is what it’s about. This is what Web development is about.

Authors, prioritize HTML. Don’t be ashamed and don’t be afraid to talk about HTML. It’s not just the basics. Who wants to hear the basics? I just talked about the basics, and I feel pretty confident with my talk today.

[Audience laughs]

Manuel: So, don’t be ashamed to talk about HTML. Please, go out there and speak and write about HTML. And please don’t write one of these shitty clickbait-y “Ten elements you’ve never heard of” articles.

[Audience laughs]

Manuel: Nobody wants to hear that.

[Audience applause]

Manuel: Write a proper deep-dive. Take a single attribute, take a single element, and write everything and research everything you know about these elements.

Remember, markup is your friend. We heard it yesterday. When you write an article about CSS or about JavaScript, use accessible HTML in your demos. Even if it’s not about the HTML, make sure that you’re not just using random divs. Use proper HTML. You might even add some side notes and explain why you are using this and that element.

Please learn how to test your sites with automatic testing tools. When we look again at the WebAIM One Million report that I cited, they found automatically detectible issues on 96.8% of these one million websites. That’s quite a lot, I would say.

These things are detectible. Use Accessibility Insights or DevTools or Lighthouse or WAVE. You press a button, and they will show you all of these errors.

Learn how to do that and, please, if possible -- you would make me really happy -- learn how to test your sites with the keyboard and screen readers. It takes some time, yes. It’s complicated, especially the screen reader part. But try to learn that stuff. It will help you. It will help your users. It will help your products.

[Loud exhale] Okay, that’s it. That’s all I have to say today.

Um... are there more things that might be a reason why the quality of our markup is so bad? I’m pretty sure that there are more things, and there are also definitely more things, more advice that I have for you, but that’s all I have for now. I don’t know more at the moment.

I just guess I have to go back to my hotel room and do some thinking and think about HTML. But for now, all I have to say is thank you so much for watching and enjoy the rest of the conference.

[Audience applause and cheers]