The Future of HTML We Want to See

HTML5 was first released in a public-facing form in January 2008. While we wait for everyone to eventually drop IE11 support so we can actually use newer additions to the specification like, dialog and progress, there remains a world of common web UI that isn’t currently supported by the aging standard. Both the WHATWG and W3C are currently working towards new standards to be adopted by the HTML spec, and what makes it to the final version will have ramifications for the web accessibility landscape.

Background

The HTML specification provides browsers (also called user agents) a standard to build features around. Consider one flagship HTML5 feature: the <video> tag. Before this element was introduced, site authors who wanted to feature video content on their web pages relied on a third-party plugin called Macromedia Flash. This plugin enabled browsers to play .swf or Flash files. It required end-users to install third-party software, which required frequent updates, at a time when bandwidth on the web was much slower and less reliable than what we have today.

It also meant that the content within those video and flash files was often inaccessible. When browsers render web content within the HTML spec, they can interpret meaningful semantics about that content. Consider an <img> tag. A browser can identify attributes that provide the image meaning, such as the Filename, the image’s Height and Width, and crucially Alternative Text, which describes the image to those who can’t see it (or whose internet connection is too slow to render it). This was not the case when it came to embedded .swf files and flash content – their meaning was obfuscated and invisible to browsers, leaving many users in the dust about what the content was or how to use it.

With the advent of HTML5 video, content authors could provide the browser with meaningful video content the same way they could for images. The user had the ability to Play/Pause, seek a track, and set volume in real-time. Even subtitle tracks could be added, affording the hearing impaired a suitable experience. All of this was now available without downloading and installing additional software like Flash.

What’s at stake?

In the years since HTML5 was released, creatives and engineers have developed all sorts of new UI to convey various types of information to their users. Many conduct deep UX research into what makes information easy to understand or interpret. Accordions, carousels, and other UI elements have muscled their way onto the scene. However, unlike Flash video, one third-party publisher does not make these features available. Instead, engineers write javascript (a powerful and core feature of what makes the internet work in the modern world) to create these features in the browser. Similar to the gold rush of the American west, everyone raced to build their own versions of these components. 

In their infinite creativity, engineers of the modern internet found thousands of ways to build the same components. To the average user every carousel or chat window looks mostly the same, but under the hood these are assembled in a myriad of different ways. The unfortunate truth is that, while many of us are rallying to build a more accessible internet, others are still ignorant of or lack expertise in accessibility.

The end result is a smattering of similar-ish web components that leave people with disabilities in the (metaphorical) dark. Where the able-bodied of us are blissfully clicking around and deftly navigating sites tailored to their abilities, the code behind the scenes doesn’t always support those who may be relying on Assistive Technology (AT). 

To understand why, imagine the web like a series of lego blocks. Technically, you can build a windmill by putting a bunch of tiny 1×2 legos together in a specific orientation that forms the shape of a windmill. But there are also lego blocks that are circular or provide motion in some way that could build an actually functioning windmill. Code is the same way; just because something appears to be a button doesn’t always mean that’s how it was built.

When the HTML specification receives updates introducing new elements, attributes or APIs, browsers like Chrome and Firefox can build features to use them. When support for an element grows large enough, web designers, engineers, and authors can easily put them to use. This has cascading benefits all the way down from content authors to real users. Websites can become lighter by shedding javascript previously used to support a feature that now is built into the browser itself. People using AT like Screen Readers (SRs) can rely on consistent navigation patterns since the standards now make sure all similar components are built the same way.

The following components represent the biggest opportunities for a new revision of the HTML standard paving the way toward a more inclusive web.

1. Some-at-a-time Content

Though you may not have heard this term before, I guarantee you’ve seen them around. We examined the homepages of Fortune 100 companies, cataloged the prevalence of these components, and identified that 64% used at least one iteration of a some-at-a-time component. The term “some-at-a-time” refers to any UI that only shows you a segment of content while hiding the rest of the list from view – think: accordions, carousels, and tabs. Unfortunately, they are also not standardized or easy to make accessible. Without realizing it, a site author could build or install an off-the-shelf component that:

• Doesn’t use semantic markup
• Fails to communicate state to AT
• Lacks support for keyboard-only users

Carousels are good examples. If you’re a sighted person, think about the way you interpret something like a Carousel: you’ll see the arrows and understand them as directional controls; the dots underneath the slides will tell you both the number of total slides as well as their position in the overall list; and when the slide advances you take in even more subtle information (such as the speed and tightness of the animations) influencing your feelings about the site’s brand. When you think about it, it really is shocking how much information we take in visually and claim it’s “intuitive”!  

What happens when those visuals are stripped away? Screen readers don’t have access to any of it, so unless the underlying code is written with AT in mind, it could leave someone stuck in a mess of unlabelled <button> and <img> elements.

2. Floating UI (Chat, cookie consent banners, sticky headers, etc)

Another pattern is sticky elements like chat widgets, cookie consent banners, and ever-present navigations. Not only does it lack a standard implementation, but there are also a number of accessibility “gotchas” that can arise from their presence. While many share a standard approach with CSS, either through the sticky or absolute positioning, there’s enough diversity to frustrate the heck out of AT users.

The main issue is that there is no way to communicate the “depth” of a page for people using screen readers. SRs navigate the page from top to bottom and from left to right (based on the order of the code). Said another way, they read code in two dimensions. But floating UI and sticky elements directly counter this by creating an invisible third dimension. I’ve often seen these chat widgets placed at the bottom of the page, so a SR user has no idea it’s there unless they intentionally tab through everything, including the page footer (who ever looks at the page footer?). More thoughtful authors will put them at the top instead, but even that is problematic. Sure, maybe I want to chat and having that clearly presented to me at the start of my journey is nice… but maybe I hate chatbots, and hearing that every time I navigate feels like traversing a layer of hell. 

What I’d love to implement here is an attribute to communicate “layers” of a web page. You could have a sort of “base” layer where most of the content lives, while modal windows and popups live on “higher” layers. If screen readers could identify these similar to ARIA page regions, screen readers could be alerted to their presence and navigate to them from anywhere on the page. There’s even a CSS property that basically achieves this already for sighted users: z-index!

3. Smart Complete (searchable select fields, date/time fields with calendars)

Smart Complete or Autocomplete fields are complex; I get that. There are so many different types of data that they can support. Everything from text prediction a la the Google search bar to searchable <select> fields to fully bespoke input fields that are hyper-specific to the property on which they appear. 

To be honest, I’m not smart enough to even pretend to write up what I think it might take to solve this problem. Data can take many forms, and text prediction algorithms vary. But it is a problem worth solving. The only alternative is the slow, grueling slog of turning every web author into an accessibility expert. While accessibility is indeed catching its wave right now, and more and more product roadmaps are accounting for it, I don’t know that the disability community can wait another decade while we “level up.” We need more robust components today!

What would standardization fix?

For any of the components I’ve listed here to achieve an accessible experience that works for users of any ability level, authors and engineers need to write a good deal of javascript. This is because the functionality isn’t baked into the browser, and thus the information has to be communicated another way.

For example, let’s look at an accessible carousel forked from Accessible360. Below you’ll see a fairly simple carousel with arrow buttons, slides, and indicator dots. What seems simple on the outside requires over 100 lines of javascript to turn the visuals into something that a screen reader can interpret.

To see how it works please visit Codepen to see the carousel with good markup.

Immediately, standardizing this pattern would eliminate the need for 80% of this code. Instead, browsers like Chrome, Firefox, and Safari would have a blueprint to implement this functionality directly in their applications. Once updated, the javascript implementations would no longer be necessary, and we could see accessible, performant implementations of the same carousel above in as few lines as:

<carousel type="single">
  <slide id="firstSlide" value="Slide 1" selected="true">Slide 1</slide>
  <slidecontent for="firstSlide">Content for Slide 1</slidecontent>
  <slide id="secondSlide" value="Second Slide">Slide 2</slide>
  <slidecontent for="secondSlide">Content for Slide 2</slidecontent>
  …
</carousel>

By offloading the accessibility logic to the browser, we reduce the complexity of what needs to be implemented by site authors. Not only that, but site authors would no longer need to become accessibility experts – By leveraging a native HTML component, they need to plug in their content and let the browser handle the rest. The list of benefits goes on to include more predictability between websites for people using AT and even faster sites as code gets trimmed and offloaded to the browser! Truly, a win-win-win.

What next?

I want to acknowledge that incredible groups like Open-UI are actively researching and proposing draft specifications for some elements I’ve called out in this piece. I do not intend to make it seem like these problems are easy to solve. There is a ton that goes into writing a spec that not only accounts for all the use cases needed for a particular UI type but can also can be agreed upon by all the browser teams. It requires rigorous accessibility and usability testing, getting the major browsers to agree on the implementations, etc.

So how can we push these initiatives further? Honestly, we probably all need to look in the mirror. What open-source libraries can we contribute to? What testing and research can we conduct and publish? We must focus on drafting standards that meet the needs we’re missing. From there, we can pressure browsers to prioritize supporting the new specifications. 

We at Tamman are eager to march towards new, more accessible horizons on the web. We hope that our small contributions to educating our staff and developing quality, accessible components will keep the needle from moving backward. But it’s only by forging bravely ahead as a community that we can catalyze true, lasting progress. 

___

Walt Zielinski is a Senior Digital Accessibility Engineer at Tamman, Inc., dedicated to creating inclusive digital experiences. A passionate advocate for accessibility, Wally is committed to building innovative solutions that empower everyone.