More to give than just the div: semantics and how to get them right

Hello there, I'm joining you today from Rotterdam, the Netherlands.

And this is "more to give than just a div".

I talk about semantics and how to get them right.

Semantics in its simplest definition.

Or at least at least the simplest I know of is what's stuff means.

And it isn't just a thing on the Web of course.

For literally millennia, philosophers have argued about what stuff means.

And that is the science of semantics, basically.

So some of the earliest theories of meaning they are correspondence theories, and they say that the meaning of a word is the thing itself.

So the meaning of a word like, or phrase like that glass of water is that actual glass of water.

So if I want to say "the glass is half full", you can verify my claim, and check of whether it's true or not by checking the contents of the actual class.

Now that's somewhat straightforward.

It's almost you know, I'm not making this up, but yeah, it's pretty straightforward.

I think.

Now, before I got carried away, I am trained a philosopher and yeah, I'm the philosophy of language has always kind of been my favorite part of what semantics falls on that.

So I won't bore you too much with the full history of semantics, but I do want to highlight one specific person, Ludwig Wittgenstein.

Now he famously concluded and this contradicts his own earlier work, that meaning of a word is not the thing it refers to not like a glass of water, but it's use in the language, meaning equals uses this famous phrase, attributed to him.

It's about how words are used, day-to-day in a community.

So if everyone uses water as a, you as a word to talk about water, then that is meaningful.

If some of us started to say butter instead of water, and we continue to do that, then that works for us.

Like, you know, we effective effectively exchange water using that phrase.

Now, then that starts to be meaningful.

So kind of when it starts to be used by a group of people, it starts to be meaningful.

So meaning requires that a group of people uses it in the same way.

But what if you're alone?

Wittgenstein argued that there can't be a private language.

There can only be meaning if it is actually shared.

And there's an interesting parallel, I think with a interesting parallel, I think with the web and web accessibility.

In one way, your design system is shared language.

It is a collection of shared concepts, shared patterns between people in your team in your organization.

You know, there's meaning just because you use all the same words for the same stuff on your websites.

And language plays a huge role here.

Design systems they don't work as well if developers and designers, content folks would all use different terminology for the same stuff.

It's that alignment in terms of language that matters.

The fact that you're using the same words to describe the same patterns.

Now APIs are another example of a shared language.

It's kind of like a contract in practice a contract about how a service will respond to requests if they are made with certain phrases, with certain names, certain language.

So API is, are a bit like a shared language too, or when you are working in some kind of framework component UI framework theh you know, you write codes and the names of your components a bit like the stuff in your design system not exactly the same, but similar.

They are a shared language too, in the names of files, classes or functions.

The naming and what's the core things really depends on place and culture too.

So when I first visited the US, I was surprised by the size of a small coffee and similarly peers in Germany exist in a very different scale than they do in the Netherlands.

We've got a very small ... here.

Now the classification is different or, you know, we use different categories.

And that's hard.

Categorization is hard.

It's hard for humans, but even more so when we try to have machines do classification for us.

In her fantastic book, Atlas of AI, Kate Crawford dedicated a whole chapter to categorization.

That's how hard it is.

It explains that for machines, they are not very good at classification as we may, we may wish there's a lot of problems like bias and data and, and all of that.

Semantics is all about agreeing what things are, and this can be hard.

There can be disagreements about meaning and classification.

So moving kind of from philosophy back to technology, what would that mean on the Web?

Now, we'll look at that now.

We'll have a look at semantics on the web.

You can have lots of different semantics on the web, too.

With XML schemas, you can create your own language.

For instance, if you're creating a system that allows you to do invoicing and you want to mark up an invoice, you can invent your own tags for everything on the invoice.

So all the things that exist in the world of invoicing that you've created.

With an XSD file, you can define your own schema and say, what's what in your world, which is helpful for validation and stuff.

For accessibility, we don't want a semantics that is specific to our needs.

We need one agreed upon set.

That is essential, and, that, and you may have guessed, this is HTML.

It is a standard way for your website to declare its semantics.

It is standard in the sense that every website uses it, any system that parses the website or parses the Web in general can make assumptions about what stuff is and what it means, because they're all using the same semantics, a shared semantics.

It isn't a way I should say, to declare what stuff looks like on the page.

It is, you know, something might look like a button, but you know, if it goes somewhere, the correct semantic is 'link' and not, not 'button', the anchor tag in other words.

So it's not about what it looks like.

It's really about what it semantically is.

So does HTML matter?

Yes.

It certainly enables a lot on the web as a shared system for semantics enables, for instance, a multi-device Web.

That's really exciting.

Like the first worldwide web server the first multimedia browser and web editor, they all ran on a NeXT machine, which looked like, you know, what personal computers looked like 30 years ago.

We can't imagine having a computer like that in our offices today.

But it's only thanks to HTML that the same web pages from those days can still display on today's devices and, you know, one HTML structure can be used to serve content to desktops, to tablets, even to refrigerators with different layouts.

CSS can do that of course, and CSS does the different layouts, but it can only do that because of HTML.

It is pretty much what powers the responsive Web.

Our default style sheets are another example of the power of HTML.

Because we define page structure in HTML, browsers can come up with defaults for things like headers, so that even in documents that have no styles, there can still be some kind of visual distinction.

That this would even go beyond visual style sheets.

What about screen readers, or maybe your car?

It could speak websites to you and emphasize parts of a sentence that are marked up as needing more emphasis with the emphasis tag.

And of course, yeah.

assistive ... would we do the same or they could do the same with, with speech.

Well, what about using structure to provide easier access?

Screen reader users often use headings on a page.

For instance, if they use voiceover, they can browse through a list of headings.

And that only works if headings are actually marked up as headings.

They can use that list and then jump to the section that that heading describes.

And that's really helpful.

It's like shortcuts or like a table of contents.

HTML also enables default behavior that is tied to semantics.

So if you say something is a button like by using a button tag, place it inside a form, it will submit that form by default.

So have that default behavior.

Now, what about reader modes?

If pages have useful markup like headings and lists and images, heuristics of your browser, reader modes and browsers read them, they can go ahead and render it better.

Now that's really important because in 2021 websites have intrusive ads.

They have poopy consent mechanisms.

They have paywalls and newsletter signup overlays that are rather annoying.

Some websites seem to collect them all.

And of course, then it really helpful if a browser offers a way out.

To me reader modes are a bit like, like, you know, useful tools to deal with the web of today they give users control.

So, yeah, HTML, it is really nice.

It enables us to do a lot of things given that we use it semantics correctly.

And of course, you know, the elephant in the room is that it is that not all websites get their HTML right.

Yeah.

Some of them clearly miss out of these advantages.

In fact, I'll make a point of that while I'm at it.

So.

Be sure to hire for HTML expertise for most developer roles, it is not, or hardly an issue in interviews or resume scans.

And I feel it really should be HTML knowledge in your teams can save your organization a lot of money.

Hire for this expertise or train developers and make sure they learn about HTML on the job because it is important to the end product.

All right.

So what does semantics look like in practice?

Well in practice, we'll need to look at the HTML standard.

It has a section about semantics and it explains that semantics in HTML is to be found in three places.

It's is elements, like it can wrap a text in a heading element like a H1, or H2.

And boom it now has heading semantics.

Sometimes semantics are in attributes too maybe the controls attribute on the video marks it as a video.

So marks it as something that can be controlled.

Maybe that goes a bit far to call it semantics, but sometimes attributes are, and more often semantics is in the values of attributes.

For instance, you could distinguish between email and phone input fields with the type attribute or between open and closed detailed elements the details elements with the open attribute.

So a lot of distinctions you can make through attributes.

Now, besides using semantic HTML elements, like the button, you can also opt to use the non-semantic elements like div, and then add the semantics kind of on top of that with a role attribute.

Now, in this case, I'm doing role = button using something called WI-ARIA.

That's not ideal because it only adds the semantics for a button.

It doesn't have all the other stuff that browsers do when they encounter buttons.

For instance, they will handle the keyboards.

They'll submit forms, if they're in a form with a default button type they will display a button cursor, through CSS.

So in all cases, if possible, It is much better to use the actual button element.

It isn't hard to style as, as some say, and it has the browser support comes with a lot of stuff built in for free.

Speaking of buttons, there was some controversy on Twitter recently around buttons and things.

And I, well, I can't say I love controversy, but it's kind of what Twitter is famous for.

Corey LaViska echoed that in design systems, he likes to use one component for buttons and for links.

Now, as I mentioned earlier, design systems are an example of where teams or organizations, they create a shared language.

And this can mean that there is a button style that is sometimes used for links, like a call to action link that looks a bit button-like.

If your design system collects such visual styles, then it makes a lot of sense to have a button component that semantically can output links.

Now Corey writes about or wrote about this on his blog.

And he makes very clear that semantically of course, links and buttons are not the same and visually they could be, even if we hate it.

Even if they are visually.

The same then maybe that grouping makes sense.

Maybe that's enough reason for making it its own component, especially given that.

And again, we might dislike it as accessibility professionals, there can be links that look like buttons.

This is quite common and there are even buttons that look like links like on iOS.

There are some that don't really have any background and they kind of look like links.

So maybe names are a better differentiator there.

Like, is it something that goes somewhere?

If it's something that is an action.

Now what's important to remember at this point is what we mean if we say "the right semantics" and also what we mean you know, w what we mean is what, what matters for the end-user.

The face that the end user looks like looks at is supposed to have the right HTML element, it needs to have the right HTML element.

So what I would ask the question I would ask when I work with a design system or specifically a component of it is not so much, does distinguish between buttons and links properly.

It is can it output the right semantics when I need them, and do the docs clearly explain which semantics should I pick.

You know, when a component has multiple and, and, you know, make the right distinction so that ultimately the end-user has the semantics that they need.

So as I mentioned earlier, meaning equals use as we summarized Wittgenstein's idea of meaning.

And this goes for the design system it should too.

What matters is how it is used.

So which semantics end up in the user's browser.

And how does that affect their experience and the overall usability.

So does it have the right cursor for instance, or does it use the wrong one?

It exposes the practical value of semantic HTML.

Bruce Lawson explains semantic HTML is a posh term for choosing the right HTML element for content.

Now he goes on to say that this isn't a philosophical exercise.

It has observable practical benefits.

That is the main point.

And yes, I do think that's an essential point.

So let's look at some examples of that.

We'll start with headings.

Now, as I mentioned before, if you use heading elements like H1, H2, H3, and so on users can see these headings when they use a reader mode.

That's nice.

But you're also creating what is essentially a table of contents.

That's the one I mentioned before.

And the table of contents will be useful for users of some assistive technologies.

And this is a bit comparable to when you're using a word processor and you have this feature that generates a table of contents from your headings.

So you press the button and it looks at all the headings you have.

And it says on which page they are.

Now, this is often used in documents like an academic thesis or some kind of complex business proposal.

It's really useful.

And that's kind of what you get on a some assistive tech too.

Now buttons I mentioned them before, when you use a button element for any actions that the user can perform on your page or in your app, they can find it in the tab order.

They can activate it with just a keyboard and they can even submit forms depending on the, on the button type.

And that even works with JS disabled.

So that is really helpful.

That is a nice thing of using a button rather than just a div.

And what about lists?

When you're using lists like an OL ordered lists, UL and unordered, DL, description list, users of screen readers can get information about the length of the list.

And again, users of reader mode are able to distinguish the list from regular content.

Now, if you use the auto-complete attribute on inputs, you're programmatically indicating what your input is for.

When you do that software can then act on that information.

And that's really, really helpful.

Again, for end-users.

For instance, browsers could also fill this content.

This is helpful for users who may have trouble typing.

They may be using an Input method on which typing takes a lot more time, like the type of interface where you have to enter letter by letter like some users use a stick to enter their content or you might know it from TVs where you have to type in with your remote control letter for letter.

So assistive technologies can also announce the purpose when the user reaches the field.

That can be helpful too.

And lastly for improved cognitive accessibility users can also install plugins that will insert icons for each of the fields.

And again, that makes them easier to recognize.

So, so for some users, it's really helpful to see what an input is for.

Now, what if you're using table elements?

It is helpful if you also add a caption if you use 'th' elements to say what the headings are and scope attributes to say what the headings are about-the column or a row.

Now, all of those things, they make the table a lot more helpful to use in assistive tech, because the assistive tech will use that, that table structure in order to provide them ... and affordances that make sense to people.

Now, there are a lot of tags available in HTML.

And it makes sense that as a developer, you don't know them all.

You don't know them all.

You know, many have implied semantics and really to find out when to use what I would recommend use developers.whatwg.org, and just look up what's what's for what.

It's also important to know what to avoid.

Manuel Matuzović, speaking next week.

He collects examples of what to avoid, what not to do at HTMLHell.dev.

And it is recommended reading.

It contains lots of bad practices and things to avoid, basically.

Okay.

So you're following the HTML spec.

You're avoiding the strategies that are explained on HTMLHell.

Are you there yet?

Well, for large part, yes, but there are also some gotchas.

Even with the right intentions the web platform may have some surprises in store for.

Sometimes assistive technologies will use heuristics to fix bad websites, which may even affect your good website.

So let's look at some of these gotchas now.

And the first one relates to CSS.

So when you add CSS, to your HTML it can cause your intended semantics to reset at given times.

One example of that is the display property the display property as Adrian Roselli, who is speaking also at this conference has documented in detail on his blog and other places.

Whenever you use display: block, inline, grid, flex, contents even display: none that element can lose semantics.

Maybe for none that makes sense.

But for many of the others, it does not.

Now this happens on elements, including lists and fields.

And it's especially bad on tables because they can be quite complex.

And if they break or they partially break because you've overwritten the semantics or that happens in the background, then the mechanisms that these assistive tech have in place to allow users to navigate tables will no longer work.

They require correctly marked up tables with the right markup, with the right semantics.

And that will just break.

Not only can these CSS properties affects senantics, how they do that also differs per browser.

And sometimes browsers drop more semantics than others.

And, some of them will fix the problems, some of them have fixed some of the problems already.

So it's a complex field basically.

And I feel, you know, we can consider these browser bugs mostly.

But not all of them are fixed.

So Adrian's post has compatibility tables, mapping properties to HTML elements and specific browsers.

And I'd like to refer you to that post and the talk, which I'll be sharing later.

I'll be sharing all of the links in fact of this presentation.

Now lists can also lose semantics if you undo the visual styling.

Now this has to do with tension that sometimes exists between on the one side websites and how they're built.

And on the other side assistive technologies trying to give the right experience to end-users.

Sometimes assistive tech tries to improve web content or fix bad websites, basically.

Cause really what is a list?

If you list a couple of ingredients on your recipe website and visually display bullets, then that is clearly a list.

It looks like a list.

It feels like a list and it really needs lists semantics.

There's no doubt about that one.

But let's say you have a list of products.

Maybe they are search results or some kind of category, a view of some kind-is that a liast?

Well, a set list of products, where, you know, there's no bullets and some browsers would indeed argue that there are no bullets.

So there's probably no list either.

And Safari is one of those browsers.

So if you do list-style-type: none in Safari that will not expose as a list.

James Craig who works for Apple explained on Twitter, that there is something he refers to as listitis: developers, turning too many things into lists, which was a commonly complained about phenomenon by end-users.

So Apple ended up deciding, to make the user experience better.

He explains deciding to adjust the heuristics for that.

He feels that makes sense, but he also invites suggestions.

In fact, I'll include a link to the exact heuristics, if you want to dive into the C++ of the WebKit code that actually does it, or, you know, comments on on this happening.

But it makes sense if you think about it, the way Apple does.

Something to say for that.

Now nesting also matters when browsers determined the semantics for a specific element on a page.

Sometimes browsers will undo semantics when you nest unexpectedly.

Now I recently had this at work.

I came across this when I was using a "details" element as an expand collapse.

Now, within details, if you use a "summary" element you define the content that's always there and access a toggle for the remaining content.

Now, sometimes this can make sense for the toggle to also be a heading.

So let's say I have a list of ingredients.

My content is a recipe and maybe I want to have one heading that is ingredients and another one for the method.

Maybe you'll feel having the, this heading will make the content easier to find for users od screen readers.

And maybe having the expand and collapse would make it easier for other users.

So you're trying to do the right thing and you're using the heading there.

Can we have this food and eat it too?

Well, it turns out not really not really, at least not in all combinations of browsers and screen readers in JAWS, for instance, as and I should say, and this is thanks to my, and my colleague Daniel Montalvo pointed me at is he is a JAWS user.

The headings are no longer.

Showing off as, as headings.

So they basically lose their heading semantics and then the just become buttons because they are inside a button, the button role kind of overrides everything that's inside of it.

The heading semantics go away and you just end up with only the button semantics.

So the semantics are still there for a button.

The heading no longer shows up.

And the specification says a summary element can contain phrasing content, which is basically just words.

But it can also contain optionally intermixed with heading content.

So optionally it can be mixed with other content heading content specifically.

It seems like we could call this a bug of this specific screen reader.

It is trying to do the right thing unconfuse, what they think might be confusing.

But yeah, they are removing the semantics that we intended to be there.

Now that's a common theme in many of these things, there are many heuristics that screen readers apply that could somewhat mess with your intentions.

And it's good to be aware of those.

I'll give two more examples that are really semantics related, like when you set text-transform to uppercase some assistive technologies will read it like an abbreviation.

Now that's great.

When let's say you are a railway- Great Western Railways and it's abbreviated as 'GWR'-they're fine.

These capitals represent an abbreviation.

But what if your navigation menu happens to be styled all capitals?

You know, and they are just words?.

Not an abbreviations.

Then that is a problem, and it can be annoying.

Another example.

Sometimes you might use the CSS feature called generated content to add a bit of content for styling reasons like an icon.

Now, often this content isn't just considered stylistic or decoration.

It is actually included as part of the accessible name.

So let's say you have created a button and it's the "buy product" button.

It's accessible name will be "by product" because we've put in just those two words as the text content.

And let's, let's say you decided to include an icon to that.

Maybe you will add it as generated content with ::before.

It shows up it decorates the button, it's a bit of extra decoration basically, but it doesn't stop there because now that becomes part of the accessible name and also of how assistive technologies will refer to this button.

And this might be unexpected, but it's all per spec.

You can find out about this in a specification at the W3C called, accessible name and description, computation, specification version 1.1.

And you know, again it makes sense, according to to the spec but it is, something to really be aware of, because sometimes you'll see it can indeed impact to our accessibility meta information.

All right.

So we've looked at what semantics is, how it works on the web and what specifically can affect it on your websites or apps.

Let's now have a look at the future and I'm interested in two questions there.

Firstly, does the web need more semantics?

Does the shared language of the Web kind of need to be expanded in the future.

And then secondly, do developers of the future still need to define semantics, or, you know, can machines, maybe help and take over.

Let's start with the first one.

Let's start with that first question.

So as a matter of fact, our design systems commonly contain things that don't exist as such in HTML.

So they don't have their own elements.

Like, you know, I'm thinking of tabs common components like that, or tool tips.

They often don't exist on the platform and many design systems kind of build their own.

Now sometimes we also build things that do exist, but not with the desired level or Such as components, like select elements.

What we want maybe is the select semantics, but not that the for UI.

The open UI community group at the W3C tries to change this.

And as it says on the open UI home page, we hope to make it unnecessary, to reinvent built-in controls There are three goals to open UI.

The first one is to document component names as they exist today.

So kind of looking at what are people building in their design systems?

Again, trying to find where language is shared and where maybe where our common denominators are as well.

The second goal is to come up with a common language to describe UIs and also design systems.

Now, the third is to actually try and turn some of this into browser standards.

So maybe into HTML, maybe into some stuff that goes into CSS because yeah, wouldn't it be cool if there were more built in elements that, you know, follow best practices and kind of make sense for people who work on design systems today?

I believe this work is quite a big deal, not just for semantics, but for web accessibility in general.

It's a huge opportunity because with better defaults, it will be much easier for folks to build things that are accessible, that work for people with disabilities, and also easier to teach people to do the right thing.

It will greatly increase our chances of a Web that is generally just a whole lot more accessible.

So I'm quite excited about the work that happens in open UI.

And I think that is the one way to expand the semantics we have on the web.

Now there's one more question I wanted to leave you with.

Can artificial intelligence, guess semantics so that when I don't need to rely anymore on a individual web developers to get that right.

And I can tell you that personally, I am skeptical.

I want to talk about it, but I do think that AI are notoriously bad at understanding intentions and context.

And they're both at the core of what defining semantics is all about.

Now, there may be some low hanging fruits, like a list we talked about earlier, and it might be fairly easy to guess when someone is trying to use list, but thinking back of discussion about buttons and links ealier., you know, how should a machine understand that a thing that looks like a button is actually a link.

The intentions of a web developer are essential here and maybe the future of the web will long require web developers or authors to specify really what they mean because, you know, systems cannot figure it out by themselves, even if they are super smart AIs.

And that brings me to the conclusion of today's talk.

I will leave you with the main takeaways, which are.

One that semantics only works if it is shared, so use a shared standard, like HTML.

It is the shared language for semanticson the web.

Now, secondly, HTML has many benefits and some maybe unexpected.

And lastly beware of how languages like CSS, ARIA and also assistive technologies can impact your semantics by interpreting, by having your risk takes that, you know, try to make, make sense of things.

With that.

I want to thank you very much for listening to today's talk.

I wanted to let you know that the slides and resources will be available on talks.hiddedevries.nl.

And now I will also tweet those out at @hdv on Twitter if the URLs too long and you can also find me on my blog, hidde.blog, subscribe via RSS, or get in touch via email or Twitter.

Now with that, having said all that I know there's a whole lot more fantastic talks coming up.

So I hope you enjoy the rest of the conference.

The, the lineup is phenomenal.

And I look forward to catching some of these myself too.

I want to thank Web Directions very much for having me and goodbye.