More to Give than Just the DIV – Semantics and How to Get Them Right

Shared semantics is the Web´s killer feature that allows developers create accessible experiences.

In this talk, Hidde dives into the meaning of semantics (no pun intended), how it improves your site, specific gotchas and the future.

Transcription

[Music]

[Audience applause]

Hidde de Vries: Thanks very much and can I have just one more round of applause for Marc, organizing this event in just two and a half months.

[Audience applause and cheers]

Hidde: Yeah, I can only admire this. I used to organize a conference and we need at least a year to do this, so I think that’s a great job.

Yeah, today, I’m really pleased to be here on stage. Beyond Tellerrand was my very first conference that I went to in another country (ten years ago) and I’m super pleased to be back and also on the stage.

Now, today, I want to talk to you about Web accessibility, about making the Web friendlier and better to people with disabilities, making sure that the Web works for everyone.

I have a bit of background in Web accessibility. I’ve worked as a Web accessibility consultant for a while. I spent the last three years at the World Wide Web Consortium at the accessibility team there until very recently.

Yeah, I want to talk to you about semantics specifically because it is the part of accessibility that I see go wrong most of the time. As a consultant, I work on audit reports for website owners, so they will give me their website and I will give them a report explaining kind of what their accessibility situation looks like.

There are a bunch of checkpoints that I use in the WCAG standard. Semantics is something that comes up all the time. In almost all of the audit reports that I deliver, there is a piece about semantics. I thought I will write a talk about this and see if I can try and explain semantics and how to get them right.

Semantics is something that isn’t specific to the Web. Literally, for millennia, philosophers have thought about semantics and about what that means.

Semantics is theories of meaning, and philosophers like even Plato (in super ancient times) have thought about what semantics are, about what stuff in the world. People have wondered about meaning and how to explain it.

I won’t bore you with all the details. I have a background in philosophy, so I need to stop myself sometimes talking about the history too long. But I wanted to tell you about correspondence theories of meaning, which kind of come down to this.

Here is a glass of water. If you use a phrase like that, “a glass of water,” you go maybe to a bar and you say, “I’d like to have a glass of water.” If you want to know what that phrase means, “glass of water,” correspondence theory of meaning would basically say there’s an actual glass of water and it’s pointed to that, and that is now the meaning of that phrase. The phrase “glass of water” means an actual glass of water, then point to that, and that way understand what the meaning is.

This is also how babies and young children learn languages. I have a one-year-old and I point at stuff for him to tell him, “Here is a glass of water,” and then at some point, he will start to understand that that physical thing there corresponds to that thing in our language.

Now, this has been a theory of meaning for a really long time. But in the last century, Ludwig Wittgenstein, one of the great philosophers of the 20th Century, he wrote about language quite a lot and about meaning. He used to believe something similar. He used to believe there is some kind of correspondence between objects and how we use them in a language.

When people talk about Wittgenstein, they usually compare the old Wittgenstein with the later Wittgenstein. Just before he died, he worked on this book called Philosophische Untersuchungen (Philosophical Investigations - in English).

In this book, he kind of switched to a slightly different theory of meaning. He started to say the meaning of work is how it is used in the language. What that means is he kind of supposed people use language and that is where meaning comes from.

When you talk to someone and you use certain words, that meaning starts to exist. So, it requires a bunch of people using the same words and, whenever that happens, meaning starts to emerge.

When you talk about the glass of water, the fact that we all talk about a glass of water when we see that makes that we understand that meaning in the same way. It is all about a community of people using the same words for stuff.

For that reason, Wittgenstein said there can’t be such a thing as a private language. You can’t sit on your own, make up words, and then say that they have meaning because they don’t. They will only start to have meaning when you find at least one other person that understands stuff the same way. Meaning kind of presupposes you have multiple people that understand the same thing in the same way. There can only be meaning if it is shared.

Now, what does that mean for the Web? Well, we share language as well. Design systems, for instance, are a means of a shared language. When in your organization you start to use design systems, that’s usually because you want to try and refer to stuff in the same way.

That could be in your own team. It could be an exercise if you just have one website and one team. You could use a design system to improve the understanding and meaning within your own team.

But often, that’s done across a whole organization, across many different teams, or even sometimes huge corporations have a design system that forms a shared language for their whole organization. That’s an example of a shared language. It has meaning because we’ve all agreed how to refer to certain stuff.

That’s important because otherwise, you get a developer that refers to something else -- “Hey, that’s a slider,” -- and then maybe the design folks will talk about a carousel. They may be valid words, each of them, but if you start to use different words for the same thing, that starts to be confusing. That’s why we want to have things like design systems.

APIs are a shared language as well. You kind of agree with a group of people or with a company that you interact with or your own APIs. If I’m going to send you this phrase, if I’m going to make this request, the server is going to respond with this thing.

Again, that is a shared language. It works because we have the same understanding of stuff.

It happens in many different places. If you have components, the names of your components, or maybe even file names, they also kind of form a shared language. That’s helpful because that means that we will have a somewhat shared meaning.

It’s hard, though. It’s hard to have shared meaning. If you look at that in the real world, you see often that there are differences in how people refer to stuff.

When I first went to the U.S. and I ordered a small coffee, I was surprised with what I got. As a Dutch person, we get very small servings. The same obviously also happened when I went to Germany and ordered a small beer.

[Audience laughs]

Hidde: This is different, right? [Laughter] I don’t know if you’ve ever ordered a beer in the Netherlands, but these are small cups that you get, small glasses.

Classification really depends on place and culture. If you want to put stuff into categories, you will encounter place and culture. That goes for design systems, too, if you have different cultures within your organization.

Classification is so hard that, in her book Atlas of AI, which I can recommend, Kate Crawford talked about classification in a whole chapter. She dedicated a whole chapter to classification and to kind of what it means to put stuff into categories because that’s kind of what semantics is about.

You want to take stuff and decide whether it belongs to category A or to category B. That’s what you do when you’re doing semantics, and that’s what AI researchers also try to do sometimes. They try to put stuff into boxes, and it isn’t always easy, as that chapter in that book says.

I can recommend this book. I read it a couple of weeks ago, and I really liked it, so I thought I would say that.

Now let’s look at semantics on the Web because that’s what we’re all here for, right? On the Web, you could have a lot of different semantics too. There are actual languages that allow you to define your own semantics, like XML.

Say you have a system for invoices. You may invent your own language and have tags like this is a purchase order. Here is a shipping address. This is my product name. Those sorts of things, you can invent your own language and define it in a schema. Then that starts to make sense within your community.

Maybe there is a group of companies that use the exact same structure. You’ve agreed upon something. Then that makes your whole thing interoperable, and that’s nice. Sometimes, countries or the whole world decide on a schema for something and that is very effective and nice.

But especially if you come up with your own schema in your own organization, that’s something we don’t want for Web accessibility. For accessibility, we need one agreed-upon set of semantics.

Semantics can be something that’s shared in a small group. But if we want to have semantics that is effective for Web accessibility, we need an agreed-upon set, so we need everyone to use exactly the same semantics so that browsers and assistive technologies can actually use the semantics to offer an interface to users.

We have that, right? HTML is a standard way for your website to declare its semantics. That’s what HTML is for. I will be talking a lot about HTML today. We learned yesterday that you need to look at your head. Today, we’ll look at the whole thing as well.

HTML is a standard for your website to declare stuff. It’s not a way to declare what stuff looks like on a page. So, if you want a large heading, that’s not a reason to choose the H1 element, for instance. You choose the H1 element because you want the most prominent heading or the most important one or the one that’s at the top of the hierarchy. HTML is not for what stuff looks like. It’s really for what stuff is on a page.

Now, HTML semantics is also not behavior. It’s often tied to it. Sometimes, when you pick a certain semantic, you will get certain things for free in browsers. That happens. But it isn’t about behavior, so that’s a thing to keep in mind. It is really to declare what stuff is on your page.

Now, I really like HTML. It has a lot of benefits. Some of them, you may be very well aware of. For instance, HTML enables a multi-device Web. I don’t think they could have imagined that when they invented the Web on this machine, which ran the first WWW browser. It had the first Web editor because, as you might know, the first browsers were also editors because the Web was all about consuming and creating at the same time.

These machines looked like this, and that’s not what machines look like these days. Although, I’m in this WhatsApp group with my neighbors, and we share stuff there. The other day, someone shared that they had this computer, a piece of furniture to put your computer on. They asked if anyone wanted to take over that thing. They didn’t need it anymore and they wanted to give it away to someone. It had a computer that looked just like this on there.

I presume that this neighbor actually still uses a computer that looks like this. We might sometimes forget about that if we work on websites because we all have fancy new machines. Some people don’t. People use all sorts of different devices and HTML enables that.

HTML enables a multi-device Web because it allows us to define structure. We can have languages like CSS that then allow us to define what stuff looks like visually, so the reason we could have responsive design and that we can make things work across different devices with one HTML file. Responsive Web design is enabled by HTML. We wouldn’t have that if there wasn’t HTML.

A multi-device Web is awesome. Default style sheets are great too. They’re enabled by HTML as well because if you have no styles for certain things on your website, the default style sheet is going to step in and provide some styles, at least for a default.

There is functionality in HTML that only works because of the default style sheet like the hidden attribute is realized in browsers because the default style sheet puts something to display none. So, default style sheets also work because we have HTML for structure.

What about the feature like browse by heading? Folks who use a screen-reader and who are blind, they often use this functionality to browse a website.

A screen reader can read out everything that happens on a user’s screen if they can’t see it. But it doesn’t make sense to listen to the whole website. It takes a lot of time.

A lot of screen readers have mechanisms built in that allow you to look for very specific things. For instance, headings. It will give you a voiceover. It will give you a list of all the headings that are on the page and then allows you to jump directly to one of those headings.

Again, HTML enables this functionality. The fact that we classify and say, “This particular bit of text is a heading,” allows assistive technologies to provide this functionality and make the Web work better.

Now, what about default functionality like if you put in a button on your webpage? There is some default functionality. If you stick it inside of a form, it’s going to submit that form for you. That’s something that exists on the Web and you get that because we have HTML.

Or what about reader modes? They are an affordance for everyone. They are a super useful piece of functionality because the Web these days can be quite busy. You can have web pages that have lots of ads at the top and at the left and at the right. You get paywalls and cookie warnings. There are even these annoying newsletter signups that will just pop over your screen and say, “Do you please want to subscribe to our newsletter?”

We all know them, and some people don’t like them. A lot of people don’t like them. For people with disabilities, they can be especially annoying, like people who have a brain injury and aren’t able to access content that way because it disturbs too much. They can all benefit from functionality like reader modes that will take away all the fluff and just shows you the webpage and the basic structure of it.

Now, again, this only works because we’ve got HTML. HTML allows us to have structure. With structure, a browser can provide functionality like any reader modes.

This is awesome. HTML enables so many different things because it points machines at what stuff is. Then those machines can act upon that and do useful things. That’s awesome.

Specifically, for people with disabilities, they point assistive technology at what stuff is, so there is a bit of responsibility, a big responsibility that we have as Web developers, to make sure we point machines and assistive tech into the right direction and show them exactly what stuff is and what we mean by stuff in our user interfaces.

Now, this is why, when I talk to companies and they want my advice on accessibility, I will tell them to hire for HTML expertise. I’m telling you today, do this. All of companies have that in their job ads, but a lot of them don’t either.

A lot of companies will look for knowledge of the latest JavaScript framework or maybe very much focused on full-stack development and lots of different parts of the stack. But as I’ve shown before, HTML has so many things that it enables and if you get it wrong, it can cost you, too, because it could create a webpage that isn’t accessible to everyone and we don’t want that. You could get into legal trouble as well, so it is really important to have HTML expertise on your team (if you don’t).

All right, so what do HTML semantics look like in practice? If we look at the HTML specifications, there are three places it explains that semantics are set. They are set on the element, of course. When you use a certain element, you are picking a semantic (quite often). So, when you are choosing between a table element or a fieldset element, you are making a choice about what you’re saying your content is.

Semantics is also in attributes, so the difference between a video player that has controls versus one that doesn’t is something you set using a bullion attribute, the controls attribute.

It’s also in attribute values. Yeah. A value can determine what the difference is between one form field and another. One may be for email. The other may be for a telephone number. Semantics in HTML is in all these different places.

Now, you may have heard of WAI-ARIA or ARIA for short. It defines semantics beyond HTML. The reason for that is that there are certain things that exist in platforms like on the operating system, and they exist in assistive technologies, but they don’t exist on the Web.

An example of that is tabs. You might have tabs in your Mac OS settings or something like that. Assistive tech can expose that to users. But in HTML, there was no way to build tabs. WAI-ARIA steps in and allows you to set semantics like that as a thing on top of the existing semantics.

That’s what ARIA is for, so it is designed to provide semantic information about objects when host languages lack native semantics. That’s a quote from the specification. Host languages are things like HTML. But being a very broad specification, it also applies to other markup languages like SVG, maybe even XML type of things.

ARIA is designed to provide information that doesn’t exist in HTML yet. It also explains (in the second just after that) that there are a lot of situations where ARIA is redundant because HTML kind of gets up to speed with the semantics. People work on HTML all the time, and sometimes we add new semantics to HTML. At that point, you don’t need ARIA, I think, anymore. ARIA is a Polyfill on top of HTML that adds extra semantics temporarily until HTML has gotten up to speed.

There are different places where you can set semantics. Of course, in a semantic HTML element or you can add a role attribute and tell the browser, “This element is something,” in this case a button.

It is preferred, though, to use the actual button element because you get a lot of stuff for free with that. It’s going to submit the form for you. It can work with just a keyboard - that sort of thing. And none of that works when you just add a role to a div element. Usually, you want to use the HTML element if it is available.

Now, recently there was some controversy on Twitter. “Unpopular opinion:” Don’t we love them all? “In a design system, a ‘link’ and a ‘button’ should be one component,” Cory LaViska said.

This is interesting, I think. He comes at this from a design system point of view. I can understand it if you look at what buttons and links look like officially. It is quite common for links to actually look like buttons.

You could have an “Add to cart” button, and that should probably be a button because it is an action. You could also have a “Products” button that probably shouldn’t be a button semantically because it goes somewhere. It goes to your products page or something like that.

On the other hand, you could have buttons that look like links, like you could have an “Add to cart” button that has an underline or a “Products” button that has an underline but is actually a link because it goes somewhere.

This kind of gets confusing. There’s a bit of a gray area between what stuff looks like and that’s not because accessibility experts wanted it. They got annoyed with it, but it exists in the real world.

Like Apple, who introduced this pattern where you have buttons that have underlines (in recent iOS versions). There’s a “Cancel” button that has an underline and no button-like affordances, so visually these things are kind of close to each other. For that reason, I can understand that, in a design system, you might want a component that does both of these things.

But what I care most about, and because this talk is about that, too, the right semantics just means that you have the right HTML element in the DOM. That is what is most important. Whatever it looks like visually, there are other things to be said about that because it isn’t great. But whatever it looks like visually, you want to make sure that, in the DOM, there is the right HTML elements.

What does that look like? If I go and look at semantics of a webpage and I’m trying to assess that, let’s use CNN as an example. As Harry said yesterday, it’s important to do that in conference talks.

Here’s the CNN website. There is the CNN logo at the left top corner, and then there’s a bunch of categories that allow you to go to certain parts of the news, like world news and U.S. politics.

There’s a bunch of categories and presumably, they are links. When I look at semantics, I’ll try to imagine this website and try to think about what would the role need to be for each of these things.

Clearly, if there are categories, you go to a page that have these categories on them. Probably a role of link. No, each of them. U.S. Politics, probably a link. The next one too, it’s probably a link.

That thing in the right top corner, there is a little dropdown type of thing. That should probably be a button because it does an action.

That’s kind of what I do when I look at semantics. I’ll try and see, on this webpage, what can I see here, what is available, and what should it be in the browser, like, what kind of role should it be, what sort of HTML element should I expect. Quite often, when I write reports, I find that the roles are messed up. Something that should have a role of button has something else. You could have a role of no or undefined and, obviously, that is not great because, yeah, it causes all sorts of problems.

Now, you can also look at that. Oh, sorry. I have another example. There’s a bunch of headings. Of course, you would expect that they have a role of heading as well.

Now, if you want to look at what the role is for a given element, and that’s something if you want to do semantics, that’s what you’ll be doing. You just look at what each element computes to because the browser is going to make decisions about what each element on the page is. It’s going to derive that, as I mentioned before, from the HTML element or from the role attributes.

Now, if you want to find out what all of this is, you can open your dev tools. These are the dev tools of Firefox. They have an accessibility panel there that you can use, and you can inspect elements, click on them, and then you can find out what the role is in the browser.

This is the role that’s going to be sent to assistive technologies. That’s where you want to make sure that the actual role is what you would expect.

Sometimes buttons are called “push button.” That’s what browsers decide themselves. They sometimes have different words for things. It’s very helpful with the shared semantics thing. But if it says, “push button,” that’s what you need when you want a button, so you want to make sure.

If we’re talking about design systems like do we want one component for a role and for a link and a button? Okay, maybe. Maybe that will work. But what I think is then most important to ask is, can it output the right semantics?

Visually, we don’t have a lot of control over it and it might not impact the accessibility as much. But in terms of semantics, we want to make sure that it outputs a link or a button at the right time. Often, if you have a design system, you can use that for documentation. That’s great because then you can just say what everything needs to be and maybe what the kind of decision-making process is. If it’s a complex type of semantic, you can explain that in your docs. That’s what I would look for in a design system.

All right, so we saw earlier Wittgenstein paraphrased. He said meaning equals use. When we’re looking for meaning, we are looking for how is something used. That’s what I want to do in this talk, too. Kind of look at if you are using certain semantics, what is it going to mean for end-users?

That’s also what Bruce Lawson thought we should do. He explains in his blog post, “Semantic HTML is a posh term for choosing the right HTML elements for the content.” I don’t disagree with that. He said, “It’s not a philosophical exercise. It has directly observable practical benefits.”

That is something that I’ve been looking for in this talk, too. We want to know what the exact benefits are of something and then make decisions based on that because, as I explained before, semantics is all about putting stuff into the right bucket, making the right choices, choosing the right categories, basically. If you do that, there are benefits for end-users.

For instance, if you use an H1, H2, H3, like heading elements, people are able to see these headings in their reader modes. When they open a reader mode, they don’t see everything as, like, flat text. But they actually see differences in headings. They see the largest or the most important heading as the largest one in the reader mode. That is helpful. It also allows other users to navigate by heading; users of screen readers, as I mentioned before.

One way I like to see that navigate by heading -- if I can expand on that a bit more -- in some word processing software, you can generate a table of contents. If you have a really long document, you can press a button and say, “Give me a table of contents,” and it’s going to look at what the page numbers are. It’s going to keep them updated for you as well, so if you decide to add another section about something, the page numbers will automatically update.

It's something that people use when they write long business documents or maybe academic documents. It is really helpful, and it’s kind of how I like to see headings on web pages as well because when you look at the webpage, you also want to see those headings as a table of contents. When you write a heading, consider how it would show up in a table of contents too.

Now, I mentioned before; if you use a button, that’s helpful because it can submit a form for you (at least in its default type) even if your JavaScript failed because HTML and browsers are capable of submitting forms without JavaScript. You can also press it with just a keyboard, and you can find it in tab order. That means when someone goes to your website with just a keyboard, and they use the tab key to go to different parts of your interface, it’s going to show up, and that’s helpful. That doesn’t work when you just have a div element with a role of button. If you use the button element, that’s helpful for people.

If you use lists like OL, UL, and DL -- they stand for ordered list, unordered list, and description list -- people can hear that it is a list when they’re using a screen reader. It’s going to tell them, “Here is a list. It’s got five items, and this is what they are for.” That’s really helpful.

They can also still see that it’s a list when they are using reader modes. If there are bullets in your design, there will also be bullets in the reader mode. That’s helpful because you’ve picked those bullets for a reason.

If you use the autocomplete attribute on inputs, that’s also very helpful because you’re distinguishing between different types of elements in your form. You can do things like saying this form field is for street address. This form field is for the last name, or that one is the first name.

If you’re making these distinctions in your code, that’s really helpful because people can then tell their browser to fill in data for them. That is helpful for everyone, but specifically again for people with disabilities who may be using an input method that isn’t so fast, like they may not be able to use a keyboard. They use a switch control, which will let them input words letter-by-letter, or they may be using voice control. These are all input methods that aren’t as fast, maybe, as a keyboard. If their browser can automatically fill in information for them, that takes away a lot of effort and that’s just generally really helpful.

Assistive technologies can also announce the purpose for an input. That’s helpful. And autocomplete attributes are also helpful for personalization. That’s something that people are working on in the cognitive accessibility space.

There are certain cognitive impairments that make it really hard for people to use user interfaces. One way to make it easier is to personalize the interface with icons.

If you have a big form and there is an email field and a telephone field, if you are able to display email icons and telephone icons right next to those fields, you are offering a way for people to recognize the symbols instead of reading the text. For some disabilities, that’s actually really helpful.

For personalization, again, autocomplete is really helpful, too.

Then if you’re doing tables, which is something you should be doing if you have data on your page, assistive technologies are often really well equipped to navigate tables. There are a lot of mechanisms for people to browse the table and understand it better if you use the right semantics.

If you specify that it is a table, if you specify what the caption is so that the assistive tech knows what to refer to, and if you use scope attributes for direction, so you’re saying like, “This applies to the column, and this applies to the row,” that sort of semantics really help people navigate tables with assistive tech.

Yeah, by now I hope you understand HTML specification is really helpful and you want to find out what everything is for and use everything in the way that it is intended so that we can really have a shared semantics and that browsers and assistive technologies can optimize your webpage for users in a way that works for those users. That is really helpful.

I can recommend the HTML specification from the What Working Group. It’s on developers.whatwg.org. This specific version leaves out all the details that are mostly relevant for browser makers, so it has just the information that’s helpful for developers.

I can recommend that. It’s got good search functionality as well.

If you want to know how not to use HTML-- [Laughter]

[Audience laughs]

Hidde: HTMHell is an awesome website by Manuel Matuzovic. He explains also taking examples from accessibility audits that he does or ways not to use HTML and explaining what sort of problems you are causing in these places. That’s a great website to find out what not to do.

By now, I hope we all have great intentions. We want to make sure that everything on our webpage is marked in the right way so that the semantics are clear for browsers and for assistive tech. But it doesn’t always mean that everything will be perfect. There are some caveats that I wanted to talk about so that you know what to look out for.

For instance, if you use certain CSS, it could get rid of your semantics. It could destroy the effort you’ve made to do semantics.

One example is the display property. When you set, for instance, a table to display grid, what could happen in some browsers is that it takes away the table semantics. I just mentioned table semantics are really helpful for end-users, especially those with assistive technologies, because it allows them to browser better. If you remove those semantics, all those benefits are gone.

There is a great blog post about this, that goes into much more detail, by Adrian Roselli. I will be sharing my slides and resources later, so you can find him online.

Basically, he maps these properties to different semantics and then different browsers to find out what’s missing where. The landscape is quite varied, so there are a lot of problems with a lot of different browsers.

Something else that happens is that lists can lose their semantics when you use list style type none, which is basically done to remove the bullets from your lists. In Safari, what will happen is that it will take away the list semantics.

If you have something like this, a list of ingredients, you want bullets and you see bullets visually. That’s going to be fine. But when you’re building something that doesn’t show bullets but might qualify as a list, like a list of products, maybe -- here, I’ve got six products, so maybe they are like a list -- I might use a UL element for that. But in Safari, it’s going to take away those semantics altogether because Safari thinks that it’s better for end-users to not have too many lists on a page.

They don’t just think that. They base that on actual user complaints, as James Craig (who works for Apple) has explained on Twitter. I’m a bit torn between whether this is good or not. Apparently, some users will complain about something they call list-itis, like having too many lists on a webpage. Safari decided to optimize for those end-users and say, “We’re just going to take away those list semantics.”

They basically have done that on purpose. They said this decision was all about the users’ experience on the majority of pages where Web developers were not paying attention to the screen reader experience.

Yeah. They’ve done this on purpose. I’m not sure if it’s great, but I can imagine too many lists is not great.

If you think about it. Everything is a list in some way. If you have a bunch of products, yeah, that’s a list - maybe - clearly. But you can go too far, like you could say a paragraph is a list of sentences. A sentence is a list of words. Maybe your word is a list of letters. It can go quite far, so you do need to know where to stop. In this case, Safari decided to step in.

Sometimes, semantics are also undone when you do some nesting. That’s something to look out for.

Maybe you’re familiar with the details element. That basically brings native expanse/collapse type of functionality to the Web. With the details element, you can put some information in a summary element, and they’re nested inside of that, and then if it comes and expand/collapse.

In this case, I’ve put the word “ingredients” inside my summary element. It’s just showing the word “ingredients.” Then when you click that, it opens and it shows the rest of the content that’s inside that element.

Now, that’s really nice. The WAI website that I used to work on has a lot of this kind of expand/collapse, and what we would often do is put a heading inside of the expand/collapse part.

In this case, the word “ingredients,” we’d make that a heading because we felt it would be useful (if you navigate by heading) that you can find this heading directly. Maybe for recipe, that makes sense too. You’ve got ingredients and you’ve got maybe method, and you want to jump directly there.

Sadly, what happens -- and I should thank my former colleague, Daniel Montalvo, for finding out. He’s a user of the JAWS screen reader, and he has found out that the heading semantics actually disappear when you do something like this.

When you put a heading inside of the summary element, the summary element is a button. That kind of destroys any semantics within it. The heading semantics completely disappear. It no longer shows up in any lists of headings, so the kind of benefit you were trying to find with the heading element disappears there.

This might have to do with a specification. I haven’t been able to find out the history. Currently, if you look at the specification for the summary element, it says that you can put phrasing content in there. That’s basically words, spaces, and optionally intermixed with heading content. That’s things like headings, so it seems like (according to the specification) it is okay to put a heading inside of the summary. I believe it used to be different and it used to be not allowed. Maybe that’s why some screen readers decide to hide the headings.

I do feel it’s about because it could be helpful to have this kind of double semantics where if you go there and you want to push the button, it is a button. But when you use browse by heading, you also want it to be a heading. They are not exactly the same element, so it feels to me like it would be nice to have those two semantics, but yeah. It depends on what makers of browsers and assistive tech decide as well.

Now, sometimes there are also heuristics in the platform and in assistive technologies that kind of get in the way. For instance, if you have text that you put into uppercase with CSS, so you do a text-transform uppercase, that will sometimes become an abbreviation. So, if you have a word and you put it in uppercase with CSS, it will be read out by a screen reader as an abbreviation, so letter-by-letter.

It might be nice if you are GWR (the Great Western Railway). Maybe it’s going to read out that abbreviation as G-W-R. Maybe that makes sense because otherwise, it would be like “jer” or something, and that’s not helpful.

But if you have all of your navigation in capitals because you think that’s pretty or something like that, it’s like for visual reasons, then it’s not helpful that it’s going to be read out letter-by-letter. Sometimes, you want it. Sometimes you don’t.

Another place where CSS kind of interferes with accessibility is when you use before and after, so pseudo-elements. They are included in the accessible name.

Let’s say you have a button that says buy this product, and you decide it would look a bit better if you put an emoji in. You could do that through CSS. You can use before, and you can stick that emoji in the content property.

Now, what will happen is that will become part of the accessible name. So, when someone uses a screen reader, that’s going to read out the emoji as well as the button. So, it’s not going to see that as just style, as a decoration, which I think is what CSS is for. But it’s actually going to take that as part of the content. And the reason for that is that sometimes developers will put important content inside of their before or after. They want to make sure it does display, so yeah. That’s actually according to the specification, in this case.

There’s a specification about how to compute names, and this whole before/after thing is actually in that specification. It is according to spec, but it may be still something that you feel isn’t great or unexpected, at least.

We talked a bit about semantics, and I wanted to have a very brief look at what it can look like in the future because semantics aren’t done, as I explained. The meaning kind of exists because we have a community and they use certain words in certain ways. Of course, the Web develops, so maybe semantics would also develop.

Our design systems commonly have things that don’t exist in HTML. That’s quite common, like tabs and carousels. We don’t have them in HTML, but we do have them in our design systems.

Sometimes, design systems also have things that do exist in HTML like select elements, but you can’t style them with CSS in the way that you expect it. Again, we sometimes lack style ability there.

Now, there is an effort called Open UI that hopes to change this. Quoting from the website: “We hope to make it unnecessary to reinvent built-in controls,” which is what a lot of people do. People invent their own tabs, which are not built-in, but people also make their own select elements, which are built-in. There are a lot of things that don’t exist yet in HTML, and Open UI is looking at making some of that happen in HTML.

Open UI works on documenting component names, so kind of comparing different design systems. They work on a common language for describing what stuff looks like on a page. They are basically involved with semantics and also browser standards to make some of these ideas a reality.

One of the things that Open UI currently works on is tabs. Something else is popovers, like tool-tip kind of things. And another example is carousels, which maybe you need them, maybe you don’t. But if you use them, it could be helpful to have a shared semantic so that everyone has the same understanding and browsers understand it in the same way as we do, as Web developers and designers.

Yeah. If you find this stuff interesting, go and look on the Open UI website. There is also a Discord that you can join, yeah, and look at.

Open UI is a community group at the W3C, which means that it is open to everyone. You don’t need to be a member of the W3C. So, if you find this stuff interesting, join us.

One last question that I want to leave you with, and maybe that’s something to discuss in the break: What about AI? I mentioned before, Atlas of AI, a book I really enjoyed that talked about categorization and that it is really hard.

I believe this to be really hard, so could an AI figure out what’s on your page and distinguish between this is a heading, this is a button, that’s a form? Could it do that reliably? I am not sure.

I’ve heard in the hallways just yesterday that there are browser makers working on this very thing. If you have the data, you could probably do quite a lot in machine learning. But I think that’s a good question to talk about in the break and figure out what people think about that.

I wanted to just summarize a couple of the things that I’ve talked about. One is that semantics only works if it’s shared. You can’t have a private language, as Wittgenstein said. You can’t have private semantics. You need something that’s shared, and the HTML standard contains that.

HTML has many benefits. Some are unexpected. Be an expert in HTML if you can.

Then lastly, be aware of how CSS, ARIA, and assistive technologies can impact semantics because they sometimes do. Yeah, make sure to double-check in your accessibility tree or in the browser that you’re using the right semantics.

With that, I want to thank you very much for listening to me today, and I hope you enjoy the rest of the day as well.

[Audience applause]