# data[].attributes.blurb.html
As web developers, a large part of what we can do to improve the accessibility of our sites and apps, is in markup. In this talk, you’ll learn how the markup we write impacts the Document Object Model (DOM) and Accessibility APIs. We’ll look at specific examples and how to optimise them for end users. Lastly, we’ll peak into upcoming changes: how will the Accessibility Object Model (AOM) help us in the future?

# data[].attributes.slidedeck.data[].slides[].desc.html
Hello JSConf! Tejas was absolutely correct, this talk is about HTML.

# data[].attributes.slidedeck.data[].slides[].desc.html
So in the next 30 minutes, sorry to disappoint, unlike Lucky, I won’t be flying drones with bananas… that was a great talk wasn’t it? I will also not hide gorillas in these slides, as Moran did, or combine the history of art with the awesome possibilities CSS has today, like Nils… instead this talk will be about HTML and what it can do, for you and for your users.

# data[].attributes.slidedeck.data[].slides[].desc.html
HTML is awesome, because it enables lots of things.

# data[].attributes.slidedeck.data[].slides[].desc.html
It enables a multi device web… we use CSS to create experiences that work across device and viewports and what not… the reason we have a structure to program our CSS against: HTML!

# data[].attributes.slidedeck.data[].slides[].desc.html
HTML enables browsers to come with sensible defaults. Maybe your project uses a CSS reset, but there’s likely still styles that are set by the browser, like table styles to make stuff appear next to other stuff, and all sorts of other things, have you ever stared at the computed styles in dev tools?

# data[].attributes.slidedeck.data[].slides[].desc.html
There’s browse by heading, which I’ll get into in a minute.

# data[].attributes.slidedeck.data[].slides[].desc.html
Default behaviors are enabled by HTML, so like buttons would submit a form by default and the browser knows to do that because HTML exists.

# data[].attributes.slidedeck.data[].slides[].desc.html
Or reader modes… which are essential for people with certain disabilities and nice for us all, on today’s web that gets more and more complicated over time.

# data[].attributes.slidedeck.data[].slides[].desc.html
Ok, so my talk is called It’s the markup that matters, I guess that won’t surprise you now. Let me tell you why over the next 30 minutes!

# data[].attributes.slidedeck.data[].slides[].desc.html
First, I haven’t introduced myself, I am Hidde, i do dveloper relations at Sanity. We’re on a mission to make content easier to work with for content creators, developers and even businesses… the end goal is more delightful, remarkable digital experiecnes. In recent years I also did a lot of accessibility work, most recently at the World Wide Web Consortium, promoting web standards for accessibility. And I blog, you can like and subscribe at hidde.blog, or follow me on Twitter, I’ll post my slides there too.

# data[].attributes.slidedeck.data[].slides[].desc.html
So let’s talk about accessibility.

# data[].attributes.slidedeck.data[].slides[].desc.html
In its simplest form, web accessibility is all about ensuring people with disabilities can use your site or app.

# data[].attributes.slidedeck.data[].slides[].desc.html
Or, to phrase it differently… it is to ensure they can buy your product.

# data[].attributes.slidedeck.data[].slides[].desc.html
Or use your service.

# data[].attributes.slidedeck.data[].slides[].desc.html
Yesterday there was this show of hands around who is or knows people with a disability… the stats don’t lie, many of us have disabilities, in many shapes and forms, from neurological conditions to motor impairments.

# data[].attributes.slidedeck.data[].slides[].desc.html
Like, a lot of people use high contrast modes.

# data[].attributes.slidedeck.data[].slides[].desc.html
Or zoom in on websites, which low vision users do to access the content.

# data[].attributes.slidedeck.data[].slides[].desc.html
Some people prefer reduced motion as motion could make them sick, literally.

# data[].attributes.slidedeck.data[].slides[].desc.html
Lots of people don’t use a mouse, for a variety of reasons… they might be using a switch control or use their voice or use a keyboard.

# data[].attributes.slidedeck.data[].slides[].desc.html
So, many things to optimise for, which is why everyone in the team has some accessibility responsibilities. But today I want to focus.

# data[].attributes.slidedeck.data[].slides[].desc.html
Today, I want to focus on specifically people who use assistive technologies, as that’s the part where code and developers make a huge difference.

# data[].attributes.slidedeck.data[].slides[].desc.html
It’s tech like voice control that lets users control their computer by voice, switch controls, braille displays that translate what happens on the screen into braille in real time and screenreaders. All of this tech exists so that people can use computers and the web in a way that works for them.

# data[].attributes.slidedeck.data[].slides[].desc.html
Our markup hugely impacts the user experience, let’s look at how.

# data[].attributes.slidedeck.data[].slides[].desc.html
When someone accesses your site, let’s say they type in a URL and press enter, your server is going to respond with markup. The browser turns that into a DOM tree.

# data[].attributes.slidedeck.data[].slides[].desc.html
From the DOM tree, the browser creates a secondary structure called the accessibility tree. It has things like here’s a radio button called ‘Round trip’ that you can press and it is selected, a slider that can go from 0 to 24 and it is set to 7, it’s called ’Departure time’ and you can increment and decrement it. A button that is called ‘Search’ that can be pressed. By now you may be able to visualise some kind of UI that allows users to do the things defined here in the abstract. Assistive technologies do this too, but they use interfaces specific to their user group.

Example of an Accessibility Tree (image of description above)

# data[].attributes.slidedeck.data[].slides[].desc.html
For each accessibility-relevant DOM node, accessibility trees have information on what kind of thing an element is, like is it a button or a link, or a text input… that’s called the ‘role’. There is info on how to refer to it, these are the name and description, stuff like this button is called ‘Save details‘ or that slider is ’Departure time‘. And then there is some more meta info like is this thing selected or checked or expanded.

# data[].attributes.slidedeck.data[].slides[].desc.html
When I audit a website for accessibility, I’ll be looking for this sort of information. Among other things. So if I see a website has a bunch of links, I’ll go and check…

# data[].attributes.slidedeck.data[].slides[].desc.html
Oh cool, this one has a role of link, name is “World”

# data[].attributes.slidedeck.data[].slides[].desc.html
another role of link, with the name “US politics”… ok let’s skip that one for now.

# data[].attributes.slidedeck.data[].slides[].desc.html
then there is a role of link with the name “Business”

# data[].attributes.slidedeck.data[].slides[].desc.html
and a role of button with the name of “Edition”. I guess I can find different editions of CNN dot com there.

# data[].attributes.slidedeck.data[].slides[].desc.html
So as mentioned, our markup informs the DOM tree, out of that the accessibiliy tree is constructed, that’s the story so far. From there on, information is passed to so-called Platform Accessibility APIs that are built into all the major platforms, Windows, Mac, Linux, mobile OSes… and then from those APIs, ultimately the assistive tech is informed, and with that, the user. So, our markup matters, it impacts the AT, ultimately.

# data[].attributes.slidedeck.data[].slides[].desc.html
You can look at accessibility trees in all major browsers, there are tabs available and popups that show up when you inspect elements. If it mentions roles and names and states you now know what they are.

# data[].attributes.slidedeck.data[].slides[].desc.html
Ok, so what does that look like in practice?

# data[].attributes.slidedeck.data[].slides[].desc.html
Let’s look at some examples… and don’t worry, the following examples work with all of your favourite tools)… whatever generates your HTML for you, it’s all going to go into that same DOM and interpreted the same way. All tools are welcome here.

# data[].attributes.slidedeck.data[].slides[].desc.html
One question markup answers is “Where am I?” When a screenreader user arrives on your page, they will hear what’s inside your ‘title’ element.

# data[].attributes.slidedeck.data[].slides[].desc.html
This is often an element that is somewhere in a template we never go… but this means it’s super important to keep it up to date and have a fresh title for each page, including in single page apps, where you might need to update this on route.

Code example: <html lang=”nl”> <head> <title>It’s the markup that matters Presentations - My site</title> </head> <body> … </body> </html>

# data[].attributes.slidedeck.data[].slides[].desc.html
A cool video about this is on Smashing TV with my friend Léonie Watson, accessibility expert and screenreader user, who explains that the title confirms to her that it is the page she intended to reach.

# data[].attributes.slidedeck.data[].slides[].desc.html
Another question markup answers is “What is on this page?” It’s done with headings.

# data[].attributes.slidedeck.data[].slides[].desc.html
So whenever you use <h1>, <h2>, <h3>, people can see headings in reader mode, but also they can navigate by heading. Most screenreaders have a way to access headings of a page, and it lets jump people directly to that heading, so it’s a way to find content fast. It’s a bit like when you call a customer service and they say something like “Press 1 for support, press 2 for sales”, but based on your headings on your website.

# data[].attributes.slidedeck.data[].slides[].desc.html
For this reason it’s so important to ensure the headings are well written.

# data[].attributes.slidedeck.data[].slides[].desc.html
Another question you can answer with markup is: which areas are on this page? Like, remember yesterday when the organisers started explaining the venue and pointed out there are toilets, community lounge, sponsor booths, et cetera

# data[].attributes.slidedeck.data[].slides[].desc.html
With landmarks in HTML you can do that sort of thing but for your page.

# data[].attributes.slidedeck.data[].slides[].desc.html
HTML has some elements built in that are landmarks natively, if you use them in your code you are basically establishing a landmark.

# data[].attributes.slidedeck.data[].slides[].desc.html
There’s a great article about using landmarks carefully and what to look out for called “Accessible landmarks” by Scott O’Hara, recommended reading if you want to get started using landmarks. One takeaway from this post is that you shouldn’t use too many. Thinking about the venu here, you wouldn’t want the organiser to point out every single chair in this hall, that would not be a meaningful thing to do.

# data[].attributes.slidedeck.data[].slides[].desc.html
Landmarks are currently only available in screenreaders. I’m going to embarrassingly quote my own presentation here… I did a talk a few years ago about what browsers could do about accessibility and one of the things I proposed there was browsers to expose landmarks so that sighted users could use them too. I’d still love to see that!

# data[].attributes.slidedeck.data[].slides[].desc.html
Ok, let’s move to form controls. There is a ton to say about them in terms of accessibility, I’ll focus on just one today, which is the accessible name. There’s this non profit called WebAIM in the US who look at the accessibility of the top 1 milion websites every year.

# data[].attributes.slidedeck.data[].slides[].desc.html
In the 2022 survey they found almost half of the websites they looked at had unlabelled form fields.

# data[].attributes.slidedeck.data[].slides[].desc.html
So, form fields like inputs, radio buttons, checkboxes, selects, textareas etc need to have labels, it gives them an accessible name in the accessibility tree.

# data[].attributes.slidedeck.data[].slides[].desc.html
Let’s say you use this code to write an input people can put their city into:
<div class=”form-item”> City <input type=”text” /> </div>
In the accessibility tree it is going to show up with a role of ‘textbox’ or ‘entry’ and a name of null or empty string.

# data[].attributes.slidedeck.data[].slides[].desc.html
Browsers have lots of ways to figure out what an input is called, to find the name, this is all specificied in a name and description computation specification… find the link for more details on that.

Source: Accessible Name and Description Computation 1.1

# data[].attributes.slidedeck.data[].slides[].desc.html
For now, I’ll give you one way to do it, which is to add a label element around the word ‘City’ and then relate it to the input using a for attribute on the label that corresponds with the id of the input.

Now the accessibility tree computes a role of ‘textbox’ / ‘entry’ and a name of ‘City’.

Code:
<div class=”form-item”> <label for=”city”>City</label> <input id=“city” type=”text” /> </div>

# data[].attributes.slidedeck.data[].slides[].desc.html
Then I’d like to mention table semantics.

# data[].attributes.slidedeck.data[].slides[].desc.html
There seems to be an urban myth that tables are bad for accessibility, but they are actually a great way for users to navigate tabular data.

# data[].attributes.slidedeck.data[].slides[].desc.html
One thing to look our for, though, is to make sure to add headings and set a scope. And in terms of naming, it’s often useful to add a caption element, which has to be the first child of the table.

# data[].attributes.slidedeck.data[].slides[].desc.html
A caption can be used to distinguish multiple tables on a page, like if you have this financial documents page, and I’m obviously not in finance, but let’s say you’ll need to distinguish between different tables, say one is for 2018 and another one is for 2019, you’ll want to add those unique names into the caption element. This way, users of screenreaders can find the tables more easily and when they find them, ideally know at once if they’re the one they are looking for.

# data[].attributes.slidedeck.data[].slides[].desc.html
The last element to discuss is buttons.

# data[].attributes.slidedeck.data[].slides[].desc.html
They are awesome! I know in some teams buttons are replicated by divs, but it is actually really hard to build a good button out of a div. Buttons come with lots of stuff built in, like you can find it in tab order, it works with a keyboard and it can even submit forms with the default button type.

# data[].attributes.slidedeck.data[].slides[].desc.html
Now what about the names of buttons? This is easy-ish when there is text, the text becomes the name, basically. But what if you buttons have just icons?

# data[].attributes.slidedeck.data[].slides[].desc.html
In markup it may look a bit like this. Inside of your button element, you may have some svg content. It’s a shape but the browser doesn’t know of what or what to do with it, so it is going to compute the accessible name to null.

# data[].attributes.slidedeck.data[].slides[].desc.html
Ways to fix that include adding an aria-label attribute to the button element, with as the value the name you want. This will override any contents this button has in terms of name computation, so if you had any text in there, it will be discarded and the aria-label value will be the name. Note that there have been bugs in browsers around translating this part when putting a page into Google Translate, so that’s a bit of a downside.

# data[].attributes.slidedeck.data[].slides[].desc.html
Another way to do it is to add actual text inside of the button. You can make it invisible with a so-called visually hidden class, sometimes it is called ‘visually-hidden’, sometimes also ‘sr-only’, the main thing is not to use display none or visibility hidden as that hides content from the accessibility tree as well, so these visually hidden techniques use CSS that preservces the content, like position absolute.

# data[].attributes.slidedeck.data[].slides[].desc.html
I hope by now you are all excited about the powers of HTML. If you want to know in much more detail how to use specific elements in HTML, developers.whatwg.org is a great place, it is basically the specification that browsers and other user agents also use, but with the browser specific stuff taken out.

# data[].attributes.slidedeck.data[].slides[].desc.html
Another great website about using HTML is HTMHell by my friend Manuel Matuzovich, this page collects examples of what went wrong with explanations of how it went wrong.

# data[].attributes.slidedeck.data[].slides[].desc.html
Ok, so we’ve looked at how to use markup for accessibility support, but as we’re at a JavaScript conference I thought it would be good to look at some work in progress around taking some of this stuff to JavaScript land. The Accessibility Object Model effort happening in a W3C community group works on exactly this.

# data[].attributes.slidedeck.data[].slides[].desc.html
They aim to “develop additions to the web platform to allow developers to provide information to assistive technology APIs, and to understand what information browsers provide to those APIs”, says the AOM explainer document. Note these are mostly proposals, we’ll talk about some of the plans that are being discussed.

Source: The Accessibility Object Model (AOM)

# data[].attributes.slidedeck.data[].slides[].desc.html
The first one is actually suported in both Chromium and Safari and it is the ability to set accessibility properties like roles and states as so called IDL attributes, so rather than using a setAttribute on the element you assign directly to a property. It has the same effect though and will reflect in the DOM tree and can be changed there.

Code: const el = document.querySelector(“el”); el.role = “button”; el.ariaDisabled = false;

# data[].attributes.slidedeck.data[].slides[].desc.html
When you’re building Web Components, you may want to “bake in” accessibiltiy properties to your components though. In recent Chrome Canary you would be able to set this through ElementInternals, eg you would set _internals.role on an element to set the role.

# data[].attributes.slidedeck.data[].slides[].desc.html
IDREFs are important in HTML as they can establish relationships between elements, like in the example I showed of where a <label> tag is related to an <input> in order to provide it with an accessible name. There are many relationships like that in ARIA too. The AOM folks are looking at assigning such relationships directly, so you would do something like element.ariaDescribedBy = someOtherElement. This isn’t supported anywhere yet.

# data[].attributes.slidedeck.data[].slides[].desc.html
One reason this is being explored, I believe, is that IDREFs don’t work across Shadow boundaries in Web Components. There is some early discussion on a “cross-root ARIA Delegation API”, the explainer is on github.com/leobalter/cross-root-aria-delegation/blob/main/cross-root-aria-delegation.md.

# data[].attributes.slidedeck.data[].slides[].desc.html
It would be, quoting the explainer, “an API to forward ARIA attributes and properties set on a Web Component to elements inside of its shadowroot”.

# data[].attributes.slidedeck.data[].slides[].desc.html
The original AOM discussions also included plans to include events from Assistive Technologies, so that you could, as a developer, get events for things like this Voice Control system clicked on a button. But like it has accessibility built in, the web has privacy built in, and there were privacy concerns.

# data[].attributes.slidedeck.data[].slides[].desc.html
The current proposals describe, instead of events from Assistive Technologies that would expose a user’s disability, synthesised DOM events, so a click event would get generated for an assistive tech click, and your code wouldn’t know if had come from an assistive techology or a mouse click. It works like this in many cases already, the AOM group are documenting some of this to make sure all the different cases align with actual behaviors.

# data[].attributes.slidedeck.data[].slides[].desc.html
The last part of AOM proposals is the idea of reading the accessibility tree from JavaScript. You could already find out stuff with JavaScript now, like you could read getAttribute(‘aria-label’) to see what name it tries to set, but this would give you access to what the browser has actually computed as role, name or other property. This is great for tests! This is available in Firefox and Chromium today, though with an outdated syntax.

# data[].attributes.slidedeck.data[].slides[].desc.html
Ok, so far we’ve looked at setting accessibility meta information by using HTML and JavaScript… before I leave you, let’s talk a bit more about doing accessibility through HTML.

# data[].attributes.slidedeck.data[].slides[].desc.html
As Tiger showed yesterday, using the power of the web platform can lead to great things! This goes for HTML too, HTML comes with accessibility built in… I mean, in lots of sense, like the image and video tags have features to provide text alternatives, most form controls come with accessibility features like semantics and keyboard behavior. I love this.

But… there isn’t HTML for everything! We don’t build websites with just some headings, lists and form elements.

# data[].attributes.slidedeck.data[].slides[].desc.html
I mean, some of probably have been through the pain of building a custom calendar widget? This sort of thing isn’t really there in the web platform… there is an input type of date, but it is tricky or impossible to customise and brand.

There are a bunch of elements in HTML that never needed to be styled, but it seems like today a lot of web developers are using a lot of their time customising UI controls, or building them from scatch. At least that’s an observation Nicole Sullivan (at Google) and Greg Withworth (at Salesforce, previously at Microsoft) had. They started an initiative called Open UI to work on this problem.

# data[].attributes.slidedeck.data[].slides[].desc.html
Open UI wants to make it unnecessary to reinvent built-in UI controls. The group works on features for the web platform, be it APIs, new HTML elements, attributes, CSS features, that all try to make it easier to build UI patterns with less effort for developers, leaving more to the browser.

I’ve been in this group for a bit of a year… I mean, I’m not a browser maker or pro spec writer, but I’ve been attracted to these meetings and discussions, wanted to follow along, because I believe in what this effort could achieve.

# data[].attributes.slidedeck.data[].slides[].desc.html
I think standardised controls can be a huge opportunity for accessibility. I was chatting to someone yesterday who worked on a design system and we talked about the huge ripple on effects these things can have… you build a component badly and the badness propagates everywhere… you build it well and the goodness propagates everywhere. More standardisation around browser controls, if done well, could end up propagating a lot of accessibility features towards end users.

# data[].attributes.slidedeck.data[].slides[].desc.html
Not easy though… Nicole Sullivan tweeted about this last month, a goal is to try and have “implied accessibility semantics”, to have accessibility “handled for common use cases”, it would be chef’s kiss… but, she says, this is hard. I agree with that, from the discussions we’ve been having at Open UI, there’s a lot of considerations and sometimes they conflict. Long story short, there’s a bunch of people working in different settings to try and ensure many accessibility considerations are met.

# data[].attributes.slidedeck.data[].slides[].desc.html
I want to share two different things that we are working on at Open UI. One is the selectmenu tag.

# data[].attributes.slidedeck.data[].slides[].desc.html
Has any of you built custom selects before? Greg Whitworth surveyed developers and asked how they liked styling select tags.

Responses included:

Hard to build “search in list” UI — 27.43% of respondents

Can’t customise popup window on desktop - 11.36% of respondents

Can’t style <option> — 17.85% of respondents

Need to insert arbitrary HTML — 7.82% of respondents

Can’t style default state — 14.01% of respondents

Source: Greg Whitworth, Can we please style the <select> control?

# data[].attributes.slidedeck.data[].slides[].desc.html
So if you were to build a regular select, you might do something like:

<select> <option>Tabs</option> <option>Spaces</option>
<option>A mix of both</option> </select>
and it looks however the browser decides to.

# data[].attributes.slidedeck.data[].slides[].desc.html
With the new <selectmenu>, you would do pretty much that, in its most basic form, but replace select with selectmenu. Now you can do things like replace the HTML of some of these contents, and, what I want to show you today, style the individual pieces as if you were styling divs.

Example from FAST UI

# data[].attributes.slidedeck.data[].slides[].desc.html
So you could style h button by selecting selectmenu::part(button) in CSS and applying styles, like background-color: #f00; border-radius: 5px;

# data[].attributes.slidedeck.data[].slides[].desc.html
You could style the listbox with selectmenu::part(listbox).

# data[].attributes.slidedeck.data[].slides[].desc.html
Or the selected value with selectmenu::part(selected-value).

# data[].attributes.slidedeck.data[].slides[].desc.html
The cool thing is, you can play with it today if you have Chromium or Edge Canary and turn on the Experimental Web Features flag. Note there are known accessibility issues and all of this is subject to change. Do try this at home, just not on a public facing websites, basically, just yet.

# data[].attributes.slidedeck.data[].slides[].desc.html
The second element I want to highlight is really an attribute, this recently changed. The popup attribute would let you make popup like interfaces.

# data[].attributes.slidedeck.data[].slides[].desc.html
At Sanity, we have a component to upload images and it comes with an action menu with some image related actions, like Copy URL and Replace. This sort of thing could be built as a popup in the future.

# data[].attributes.slidedeck.data[].slides[].desc.html
And action menus is just one example of popup-like behavior, others are teaching UI, content pickers such as date pickers, form element suggestions and, as just discussed, selects.

Chrome Platform Status: The Popup API

# data[].attributes.slidedeck.data[].slides[].desc.html
What popups have in common is that they are on top of other content, that they are ‘ephemeral’, like, temporary, they’re only open when they need to be, otherwise closed. And there’s usually one at the time.

Popup API (Explainer)

# data[].attributes.slidedeck.data[].slides[].desc.html
Ok, so let’s look at what the markup for that would look like. Again, this is all still in development, but this is what it would work like according to current proposals.

So let’s build our image action menu. We’ll create a div with inside of that a heading and two buttons.

# data[].attributes.slidedeck.data[].slides[].desc.html
Then we’ll add the popup attribute to the outer div. This turns it into a popup, meaning the browser will be closing (or really, hiding) it by default. If it needs opening, you’ll be able to call a showPopup method in JavaScript. Or, and I love this, add the open behavior declaratively.

Code:
<div popup> <h3>Replace image</h3> <button>Upload</button> <button>Browse</button> … </div>

# data[].attributes.slidedeck.data[].slides[].desc.html
Let’s add an ID for that, we’ll add id=options to the div.

# data[].attributes.slidedeck.data[].slides[].desc.html
What we can do then, and here’s the IDREF again, refer to the popup from a button, by setting a togglepopup attribute on the button, with the ID of the popup as its value.

Code: <button togglepopup=”options”> Image options </button>
<div popup id=”options”> <h3>Replace image</h3> <button>Upload</button> <button>Browse</button> … </div>

# data[].attributes.slidedeck.data[].slides[].desc.html
When we added the popup attribute, we were using popup’s auto mode. Having just the popup attribute is equivalent to doing popup=auto, it is the most popup-y popup.

Another type is popup=async. An example of that would be… at Sanity, when you publish a document, stuff happens on our content servers and if all goes well, a notification, ‘toast’ type of element appears that says the publishing was successful. This is the kind of thing you could use popup=async for.

# data[].attributes.slidedeck.data[].slides[].desc.html
It’s still under discussion whether this should be a live region by default, so that an announcement of the newly appearing content is made in a screenreader, for the time being we could wrap this popup in a div with a role of alert.

# data[].attributes.slidedeck.data[].slides[].desc.html
So, if we have a div with popup async, we can leave that empty until we know the content. In JavaScript, we first find the element.

# data[].attributes.slidedeck.data[].slides[].desc.html
Then, whenever we’re in the success state, for simplicity I’ll leave all of that out, that’s for another talk, let’s say the upload was successful… we basically update the content of our ssync popup and call the showPopup method on this element.

# data[].attributes.slidedeck.data[].slides[].desc.html
Like <selectmenu>, popup is available in Chrome and Edge Canary, you can go play with it.

# data[].attributes.slidedeck.data[].slides[].desc.html
If you do, we want your thoughts! One way to get involved is to follow @OpenUICG on Twitter, tag along on Discord or even join the meetings, they are open to all, if you’re a developer building UI components your input is very much valued.

# data[].attributes.slidedeck.data[].slides[].desc.html
Ok, so, let’s wrap up!

# data[].attributes.slidedeck.data[].slides[].desc.html
Today we’ve looked at the ways HTML can and will affect your user’s accessibility trees. If you want it or not, these trees are constructed based on your markup and you can impact the info that ends up there, ensuring names, roles and states are what they should be.

# data[].attributes.slidedeck.data[].slides[].desc.html
Excitingly, there is some work happening in the AOM group on allowing some accessibility meta information to be controlled and read from JavaScript land.

# data[].attributes.slidedeck.data[].slides[].desc.html
And, maybe, if things go well, we’ll get more markup, attributes, APIs, CSS features that will make it easier to build components that have accessibility built in. Even if that’s hard, I’m super excited about this, it’s a promising future!

# data[].attributes.slidedeck.data[].slides[].desc.html
And that’s all for me today, thanks so much again for listening!

You can find these slides on talks.hiddedevries.nl, follow me @hdv or email hidde@sanity.io.

Special thanks for clarifications, input, feedback Mason Freed, Scott O’Hara, Julia Silver, Eric Eggert, all at Open UI CG

Typefaces in the slides are Bungee by David Jonathan Ross (DJR) Rasa by Anna Giedryś, David Březina (Rosetta)

# data[].attributes.resources.data[].title
Smashing TV: Léonie Watson on why semantic HTML document landmarks assist her using a screenreader (YouTube)

# data[].attributes.resources.data[].desc.html
Léonie shows how titles, landmark regions and headings make it easier for her to browse the web

# data[].attributes.resources.data[].title
whatwg/html: Add element reflection counterparts to id-reference counterparts

# data[].attributes.resources.data[].desc.html
Issue for creating relationships without IDREFs in HTML Spec

# data[].attributes.resources.data[].title
Web Components and Model Driven Views by Alex Russell - Fronteers

# data[].attributes.resources.data[].desc.html
Alex Russell’s introduction to the idea of Web Components at Fronteers 2011.

# data[].attributes.resources.data[].desc.html
At Sanity we want to make content easier to work with for content creators, developers and, ultimately businesses… so that they can have more remarkable experiences.

# data[].attributes.resources.data[].desc.html
WebAIM’s research that showed 59% of websites they checked had unlabeled form elements

# data[].attributes.resources.data[].title
W3C/WAI, How People with Disabilities Use the Web

# data[].attributes.resources.data[].desc.html
My notes on linking to translations

# data[].attributes.resources.data[].title
Could browsers fix more accessibility problems automatically?

# data[].attributes.resources.data[].desc.html
“a JavaScript API to allow developers to modify (and eventually explore) the accessibility tree for an HTML page”

# data[].attributes.resources.data[].title
What’s new in web accessibility (Google I/O, 2018)

# data[].attributes.resources.data[].desc.html
Video in which Rob Dodson and Domenic Mizzoni show what’s new in web accessibility.

# data[].attributes.resources.data[].desc.html
HTMHell collects examples of how not to use HTML

# data[].attributes.resources.data[].title
Accessible Name and Description Computation 1.1

# data[].attributes.resources.data[].desc.html
The spec that defines how accessible names are computed

# data[].attributes.resources.data[].title
Cross-root ARIA Delegation API explainer

# data[].attributes.resources.data[].desc.html
The Headings component in Tenon UI’s accessible pattern library lets you automatically have the right heading hierarchy.

# data[].attributes.resources.data[].desc.html
Which includes stats on browser support

# data[].attributes.resources.data[].desc.html
In which Brian Kardell takes a look at HTTPArchive data, specifically ‘dasherised’ elements. One of his findings: most custom elements are advertising related.

# data[].attributes.resources.data[].title
Heading structures are tables of contents

# data[].attributes.resources.data[].desc.html
More on why heading structures could be seen as tables of contents

# data[].attributes.resources.data[].desc.html
Bruce Lawson’s presentation on the AOM, from which I took this excellent advice: “built-in beats bolt-on”

# data[].attributes.resources.data[].title
Web Components as compositions of native elements

# data[].attributes.resources.data[].desc.html
It’s very cool that Web Components let us create our own custom things, but often we can actually reuse existing elements, so that we can benefit from existing semantics.

# data[].attributes.resources.data[].title
Meaning without markup: the Accessibility Object Model

# data[].attributes.resources.data[].desc.html
An explanation of the Accessibility Object Model on my blog