HTML5 with Steve Faulkner

Web accessibility takes place on a foundation of technologies, the most common of which are developed and maintained by the Worldwide Web Consortium, or W3C. Its success is dependent on how well these underlying technologies support accessible user experiences. Fortunately for us, people like Steve Faulkner devote much of their time to ensure technology specifications, such as HTML5, include the hooks that make it possible to build an accessible and enjoyable user experience for everyone, including people who use assistive technologies, such as screen reader and screen magnification software, and different display and interaction modalities, such as user stylesheets and keyboard navigation.

The web was created with accessibility as part its framework. Steve’s focus is to ensure accessibility remains a fundamental component of the web’s foundational technologies. Steve is co-editor of the HTML5 specification. He has been closely involved in other W3C specifications development, including the Accessible Rich Internet Applications (WAI-ARIA) specification. In this podcast Steve joins Sarah Horton to tell us about:

• The current status of the HTML5 specification
• How WAI-ARIA and HTML5 work together to support accessibility
• How accessibility is integrated into specification development
• What it’s like to work on a W3C specification

Transcript available · Download file (mp3, duration: 44:19, 25MB)

Steve Faulkner has been working in accessibility since 2001, first with Vision Australia and currently with The Paciello Group (TPG), where he is Principal Accessibility Engineer. He is involved with several W3C working groups, including the HTML Working Group and the Protocols and Formats Working Group, and is author of the helpful resource, Techniques for providing useful text alternatives. He is also creator and lead developer of the Web Accessibility Toolbar, a resource for evaluating web accessibility.

A Podcast for Everyone is brought to you by UIE, Rosenfeld Media, The Paciello Group, and O’Reilly.

Subscribe on iTunes · Follow @awebforeveryone · Podcast RSS feed (xml)

Transcript

Sarah Horton: Hi, I am Sarah Horton, and I am co-author with Whitney Quesenbery of A Web for Everyone, with Rosenfeld Media. I am here today with Steve Faulkner. Steve is my friend and colleague.

He is technical director with The Paciello Group. Before joining TPG, he worked as an accessibility consultant with Vision Australia. Steve has been a mentor for me since I started working in accessibility. Much of what I know about accessibility, I learned from Steve.

In addition to his day job, Steve is an active participant in key W3C initiatives promoting web accessibility. His tireless work has led to key accessibility resources, including the very helpful, Techniques for Providing Useful Text lternatives document.

As co-editor of the HTML5 specification, much of his current work is focused on ensuring the specification moves forward in a way that supports and extends all the great work that’s been done to bring accessibility to the web.

We’re here to learn from Steve about the status of the specification and whether there are changes that we should anticipate as this spec is approved and implemented.

We also want to get a sense for what it’s like to work on this spec and how accessibility concerns are addressed in that process. Steve, thanks for joining us.

Steve Faulkner: Thank you.

Sarah: Let’s start by talking about how you got involved in accessibility in the first place.

Steve: In the late ’90s, I became involved in doing some HTML development. It was at a time where if you could spell HTML then you could get a job as a HTML coder, and I did some work over here in the UK—I was in the UK at the time, and I did some workup over here.

When I decided to go back to Australia, which is my home country, I looked for a job, and there was a job at Vision Australia. At that point, I didn’t have any idea about accessibility. I had very little knowledge.

But I had an interest in working with people with disabilities, and aging people, which I had done previous to starting to do the HTML development. I did a degree in psychology. I gravitate towards social work type, career path, I suppose you could say.

It interested me to be able to combine both the technical aspects, both the HTML development work and working with people with disabilities, and hopefully making a positive difference.

When I started the job, as I said, I didn’t know anything about accessibility. This was around 2000, and it was at a time where the accessibility field was still in its infancy, I suppose you could say. It probably wasn’t an infant—it was probably more of a toddler.

My first day on the job my then boss, Andrew Arch, threw a copy of the WCAG 1.0 Guidelines at me and said, “Learn this.” So that’s where I started, auditing and reviewing websites for accessibility against the WCAG 1.0 Guidelines.

Sarah: Did you read the guidelines from beginning to end?

Steve: Yes, I did. In those days, there weren’t a lot of the resources that are available now, 13 or 14 years later. It was very much explore and find out. There wasn’t the community that we have today through Twitter, Facebook, and all those things.

There were mailing lists and there was WCAG, the Web Accessibility Initiative, but those were not exactly as user-friendly as the informal networks that have grown up over time.

Sarah: When you think about the changes from WCAG 1.0 and now, and the issues that you were encountering when you were auditing things back then, are you seeing different types of issues? Are things getting better, are they worse, or both?

Steve: Obviously, we’re seeing different types of issues in that the interactions and processes that we regularly encounter of websites and web applications are much more complex than they were at that point.

We weren’t dealing with a static web at that point, but we were dealing with web that was a lot more server-side functionality, so a lot of the processing went on the server side. You’d fill in a form, you’d input it, and then you’d get some results sent back, for example.

These days, everything happens in the browser, or a lot of things happen in the browser. The user-interface elements that you’re dealing with, you could describe them as a house of cards built in HTML.

They often don’t have the required accessibility information, such as the roles, states, and properties. They don’t work correctly with the keyboard, or work as expected they do.

Things look like a button, but you can’t use it with a keyboard, for example. Whereas, in the olden days, when people stuck more to using the basic, native HTML controls, it was a bit easier in that sense.

The complexity of the content, in general, was less problematic. Because it was less complex, there were less things to go wrong.

Back to your question, “Are things getting better or worse,” as complexity increases, then obviously new issues arise. At the same time, there’s a lot more awareness, these days, about accessibility. There’s a lot of information out there to be able to draw upon, to be able to fix issues.

Hopefully, developers, in general, are more aware of taking into account building usable and accessible interfaces from the get-go, rather than having to come back and add this stuff in all the time, even though we still do encounter that a lot.

Sarah: Then things are getting worse, in the sense the interfaces are getting more complex and more difficult to support and code accessibly, but you’re seeing, at the same time, a lot more awareness on the developer-end of things, and more resources to support accessible coding practices?

Steve: Yeah, I would generally agree with what you’ve just said. Except that I don’t think they’re becoming more difficult to make accessible because of the tools that we have available now, such as the Accessible Rich Internet Applications specification and that features that describes, that are implemented in browsers, make it a lot easier and possible to make more complex user interface elements that are non-standard user-interface elements, accessible.

Previously, they couldn’t be. In that sense, things have got a lot better. But, as I say, the complexity does breed new issues. There’ll be challenges, and we face them and find out a way to fix them.

Sarah: You do a good deal of work with W3C working groups and task forces. What about that work interests you?

Steve: The main thing that interests me is that I have the opportunity to influence and contribute to defining the standards that define the web and how it communicates. For probably about seven years now, I’ve been involved in HTML Working Group at the W3C, and HTML is the language of the web.

Every web page is written in HTML. A lot of the information that’s communicated to users with disabilities who have to use assisted technology is communicated through the HTML content and structures that are defined within the HTML specifications.

To be able to contribute to the further development of the HTML language is both an honor and a very exciting privilege.

Sarah: What about the work you’re doing right now with the HTML spec? I see a lot going on about that.

Steve: It’s got to do with process within the W3C. The specifications proceed along a particular track. They’re initially published as working drafts, and then they’re reviewed and further work is done on those.

They get input from implementers. Anybody is free to provide feedback, and that feedback is taken into account. The editors make changes to the documents.

At the same time, new features are being added as either things that implementers are thinking, “We want to have this feature,” or developers have developed some custom feature that is popular, and then it becomes standardized. There are all things constantly being drawn into the specification.

At the same time, they’re trying to stabilize the specification at a particular point to get it through the W3C standardization process. It goes through an iterative process of feedback, editing, and then moving to the next stage.

The stage we’re at in the current process for HTML5, you could call it, is that we have reached what is last call. That means that what’s in the HTML5 specification is fairly stable, all the requirements are there and the features are there.

There’s not going to be any new features added to HTML5. There’s a last call, which means that people get to provide some feedback.

Once that feedback’s been dealt with, it moves to proposed recommendation, and then, ultimately, to become a recommendation, where the content of that is set in stone, so we’ll have the HTML5 recommendation.

At the same time, we are working on the HTML 5.1 recommendation, which is essentially a super set of what’s in the HTML5 specification plus new features. And so, things are being added in parallel, there’s a number of different versions of the document.

That’s the most stable version, which eventually will be locked down. And then, there’s the continuing 5.1 spec, and that will go through the same process. In 2016, its set to again go through this process of becoming a proposed recommendation.

People in the meantime, will start working on a 5.2 so there will be further extensions. It’s a living language, things are constantly being added. What’s written in this specification is, essentially a set of rules for how browsers are supposed to implement.

And browsers being Chrome, Firefox, et cetera, are supposed to implement the features defined in the specifications. If you’re familiar with HTML, all of the HTML elements, and attributes are all defined, and what they do is defined within the specification, how they’re supposed to be implemented, is defined in the specification.

As well as that, there is lot of what we call “implementor requirements”—these are requirements on authors, how to use particular features of HTML. That’s where I have a lot of interest, is defining the author requirements, because how authors use HTML affects the accessibility of HTML.

If authors misuse the features—write the code incorrectly, don’t use the headings in the appropriate way, don’t mark up tables, use data tables correctly, without using the correct features—then that has a negative affect upon users, especially users with disabilities. I spend a lot of the time working on the text of the specification in those areas, in particular.

Sarah: I see. You’re focusing on authoring aspects of the specs, primarily?

Steve: Yeah. That’s primarily what I do. But I also, obviously, review and feedback with implementers about aspects of the implementations, but mainly, in regards to the accessibility of the implementation.

If a particular feature is a new control but it doesn’t describe how it’s going to be used by someone with a keyboard, for example, or it doesn’t seem to have those hooks in there to be able to make it keyboard accessible or provide an accessible name and label, appropriately for it, then the process is, we file bugs against the specifications, but, also, when things get implemented, we file bugs upon the software itself.

I spend quite a bit of time, filing bugs against Chrome, Firefox, Internet Explorer, and Safari, to say, “Well, this is supposed to be implemented this way, but you’ve implemented it in some other way, and it’s made it less accessible. So, let’s try to get it implemented as it’s defined in the specification.”

Or, if the way it’s defined in the specification is wrong for particular reasons, then, provide some information about the reasons and we can see if we can change the specification to fit the reality.

Sarah: You’re looking out for accessibility as the specification is built out, and how it’s supported within the browser.

Steve: That’s right. Over the last weekend, or week, I’ve done a lot of testing. There’s a process of going through this recommendation process, one of the criteria for the specification to become a recommendation is, what is defined as a requirement upon browsers for particular implementation requirements is tested.

You need to write tests, and you test that the assertions in the specification are implemented as they are asserted in the specification.

There’s a fairly big section of the specification that defines how the roles, states, and properties for HTML elements are supposed to be exposed by the browsers within the accessibility APIs in the software.

A browser must, in simple terms, if you have a button element, then that button element must be exposed with a role of button within the appropriate accessibility API. This is by the browse. So you need to go in and check that that assertion is being supported within the browsers.

You create the files, you check, you use some software that looks at what the accessibility information is, and in the case of the button element, is it exposing a role of button? And happily, it is. But you can imagine that, for the accessibility aspects, there’s a lot of testing.

That is a similar model that’s used for the whole specification, and remembering how HTML specification is 600, 800 pages long, with lots and lots of assertions in there, there’s hundreds of thousands of tests that need to be written and tested.

There’s a big effort within the W3C and within the development community to create these tests and do the testing, to show what the HTML specification defines is in-line with what is implemented in browsers.

Sarah: I seem to remember reading somewhere along the way that, in order for a specification to be finalized, it needs to be fully implemented in two browsers—is that correct?

Steve: Yeah. What are known as the exit criteria, where the thing can pass—they are not always the same across specifications—but pretty much the rule of thumb is that, if the browser has an assertion in there, that says that X must do Y, then that assertion needs to be implemented in two browsers, at least two.

Obviously, the more the better, but the whole idea is to get the features of HTML implemented inter-operably—implemented in the same way in multiple pieces of software.

Sarah: Sounds like a pretty rigorous process.

Steve: It can be. A lot of time consumed, a lot of people spending time in this thankless task, that’s for sure.

Sarah: We’re all very thankful that you are doing it. Just so you know.

Steve: Thank you. As always, what’s wonderful about doing this work is you’re working with a large community of people. A lot of people are giving their time and knowledge to improve the web.

Sarah: Pretty impressive. Another specification that you have worked on quite a deal is the WAI-ARIA spec. Could you tell us a bit about that specification, and what that’s for, and the role of that moving forward, as this new HTML spec comes into play?

Steve: Sure. I will prefix that by saying that, I have been involved with the development of the WAI-ARIA specification. But my main work has been in integrating the HTML specification and the appropriate bits of the ARIA specification. The majority of the work for that specification was done with some wonderful other folk within the accessibility community.

As I was explaining before, the button element has a button role, and that role is conveyed, or is hooked up in the software, by the browser.

Previous to ARIA coming along, there was no way for an author to set that button role within the browser. What ARIA has done is allowed authors to set that information, to expose that information, to say, “This is a role=button,” and then browser sends that information to the accessibility API, so it’s exposed correctly within the accessibility API.

For most HTML elements, you don’t need to do this because the browsers do it automatically, but as we mentioned previously, what we have is a lot of development of custom widgets—things that aren’t represented as native HTML controls—being developed, using quite often, non-interactive HTML elements that have no meaning within themselves, like divs and spans, or building on top of native controls that do have meaning, such as elements, such as anchor or link elements and buttons and things like that, but actually adding to their functionality and changing the meaning of what they are.

Before ARIA, you couldn’t do anything about that, or it was very difficult to convey the changing meaning that the author has imposed upon it through scripting and coding.

With ARIA, if you change a link into a button—I’m not saying that you should do that, but people often do it—that you can, through the use of ARIA roles, space and properties, you can provide that information to let the user know that, hey, this is not a link, it’s a button, and you can interact with it as a button. It does button-like things, not link-like things.

Sarah: When you look at that specification, are there things happening within the new HTML spec that would change how ARIA is used?

Steve: To a certain extent. There are some of the newer HTML features, such as the dialog element, which didn’t make it into 5.0 because it hasn’t been implemented. It was implemented in one browser, but it’s not inter-operably implemented, and it was very unlikely that it was going to be implemented within the timescale of the 5.0 specification becoming a recommendation, but it is still present and living on in the 5.1 specification.

The dialog element, as the name implies, provides a native dialog control. Instead of having to script divs and spans to make it look like a dialog, you can use the dialog element and it has more of the features of a dialog.

Some of the interaction that you need to script in for custom dialogs is already built in. For example, when you open the dialog and you have a modal dialog using the dialog element, the keyboard interaction is that the keyboard interaction will stay inside the modal dialog until the dialog is closed, whereas with custom elements, custom dialogs, you have to use scripting to listen for the events and control the keyboard behavior via scripting.

The good thing is that with the dialog, you no longer have to do that once it’s implemented. Another thing is that, like most user interface elements, it has a role. With custom elements, as I said with the advent of ARIA, you could add a role as well as all the other things you need to do.

You could represent it as what it is, but with a built-in native dialog element, you don’t have to do that. There’s other things like the visual effects that you get. You get this dimming of the screen behind. You get those automatically.

It makes it a lot simpler for developers to create the things that they’re already creating using divs, spans, CSS and JavaScript trickery. It’s done natively in the browser, by simply having the dialog element and controlling the display of that element.

Sarah: That sounds great. Less trickery.

Steve: Less quackery even.

Sarah: [laughs] Do you see a time where ARIA would be obsolete in the sense that there would be native elements that make those additional attributes, that way ARIA brings to the process, unnecessary?

Steve: No.

Sarah: Why not?

Steve: The reason being is that there is a lot of controls that come in and fall out of favor, but they’re never standardized. Not every type of UI control will be standardized and implemented. There’ll always be room for the use of ARIA or reasons you need to use ARIA.

Also, note that one of the things I always like to say is that people see ARIA as a bridging technology—that at some point, everything will be wonderful and we will have native support for all of these interactions and roles, states and properties.

But when we look at, for example, the humble button, as I was mentioning earlier, the button element has been around since ’94, so we’re talking about 20 years. Still today, people are building buttons out of any other element you can think of but a button.

I’m not saying that’s correct and they should be doing that, but they do it, and there’s no way to stop them doing it, because part of the integral features of HTML is that every element, whether it be a control or a paragraph element, can have interaction and events associated with it. If it can, then people will do it.

Another aspect is that the focus of ARIA is shifting to a certain extent, in the sense that instead of becoming this bridging technology, it’s starting to become the abstract layer, the way that accessibility semantics are described.

They’re starting to use ARIA as the generic way to describe the accessibility semantics for a number of platforms. What happens is that if you have an ARIA button role, that equates or maps to a number of accessibility APIs and is coded into various platforms and browsers.

In that sense, it’s being used more as a generic identifier these days. Even if its usefulness as a way to plug gaps in native functionality, that it’s got a different usefulness within itself.

To give you another example—or to give you an example, even—the way that the requirements for HTML elements, the accessibility mappings that they require, are couched in terms of ARIA requirements.

In the specifications, it doesn’t say, “A button element needs to have a button role in accessibility API X, Y, or Z on platform X.” It says, “It needs to have an ARIA button role.”

It’s describing in terms of ARIA, because ARIA provides that mapping information through a sister specification to the ARIA specification called the ARIA Implementation Guide.

That has the nuts and bolts of how an ARIA button role equates to a button in Safari on the Mac, for example, what role that equates to. I don’t know if I’m getting it across, but it’s like a dictionary of terms that are defined for a variety of platforms and software.

On the one hand, you have that usefulness of ARIA, but on the other hand, you also have ARIA-like other specifications still in development. The 1.0 version of ARIA has been shipped, but there is currently work on ARIA 1.1, which is in active development.

There’s work around, for example, extending ARIA properties to be able to describe annotation information. For example, currently there’s no way for me as an author to adequately define if I have crossed something out, using a line through or whatever in a word processing program.

There’s no way for me to convey that unambiguously to an assistive technology user through the accessibility API because there’s no semantics for that that are clearly available.

What they’re looking into in developing ARIA 1.1 is additional attributes that will allow you to describe all those sorts of things like footnotes, comments, et cetera, that typically we’re used to using within Word documents and things like that, or on the web.

You’ll be able to use ARIA to provide clear, unambiguous descriptions for those things. And also, as new roles and states are being developed, one of the new controls that has become ubiquitous, especially on mobile, is the toggle button. The “switch” is another word for it.

Previously, there hasn’t been a role for that type of control. There’s roles being added for that and for some other things, so there’s further refinements and additions as new things get invented.

The other aspect, talking about, things becoming native in HTML, one of the exciting and also potentially problematic from accessibility standpoint is the new developments within what is known as “web components.”

This is a whole suite of applications that essentially allow developers to create new HTML elements that they can use in their pages, and add new functionality. It’s like they’re supercharged custom controls, like supercharged jQuery, but they allow developers to do all these great new things.

A lot of the accessibility semantics, a lot of the information that will be required to be provided, will need ARIA to be able to do it. If anything, ARIA is becoming more important and more integral to the story for HTML going forward, rather than becoming less important.

Sarah: It seems that these things move forward in tandem, one supporting the other. How is ARIA support on mobile devices, for that switch, for example, that’s used a lot in iOS? The little on/off switch, is that what you were talking about?

Steve: Yeah. Obviously, if something like that which is still being specified, there is no support. In general, the differences, the problems associated with the support for accessibility in general in various devices is that there’s a different browser culture within mobile devices than there is in the desktop.

On the desktop, you have the four major browsers. Depending upon the device that you are using, saying if you’re using an iOS device, on the surface you might have Chrome and WebKit and even Firefox…I don’t know if you can get Firefox for iOS…but underneath it, the iOS platform, the rendering engine, the engine that powers the browser, is the WebKit engine, which is the Safari browser engine.

It’s much more dependent on one vendor or one browser engine implementing something. But on the desktop, Chrome isn’t that great, IE’s pretty shabby, but then Firefox is great, and WebKit on OS X is great, as far as accessibility support, so you’ve got some choice.

Where you have the more controlled environments of the mobile then things aren’t good. Having said that, WebKit and Apple on both iOS and OS X, they put a lot of work into it. It’s obviously not perfect, but they put a lot of work into it.

In a general sense, you would find that the accessibility support for ARIA implementation is a little bit behind on the mobile devices, for a variety of reasons.

Sarah: Recently I read, somewhere on the Twitters or something, that the alt attribute on the images isn’t required for validation with the new HTML specification. Did I get that right?

Steve: Not exactly, no. Within HTML5, the alt attribute is required. To have a conforming document, you need to have an alt attribute with an appropriate text alternative on every image element.

Except in the cases where you have an image element that is contained within a figure element that has a non-empty figcaption element. Essentially, it means that if you have a caption for an image, you don’t need an alt attribute, necessarily.

It’s quite a refined rule, and it’s quite narrow in its scope. What it’s designed to do is to reflect the reality of situations like where you have image upload sites.

You have photos sites, where you have people uploading thousands of images with no desire to add text alternatives to each of them, or oftentimes no time, or they’ll have no opportunity to do that. At least, if you have a caption, you have something that identifies that image.

If you have something that identifies the image and gives some information about the image. If you had an empty alt on there, which is what, in the past, people have put on there, what that essentially does is say, “This image is of no interest,” to the assistive technology user.

With the implementation of the HTML5 semantics for images with an empty alt, it will mean it will no longer be represented in the accessibility tree if it has an empty alt on it. It’s a way of saying, “This image may have some information of interest. It doesn’t have a text alternative, but it does have a caption.” It tells you something about the image, in that the image is there. Where, if you put an empty alt on there, then it would disappear.

Sarah: I think I got that. I understand the use case. You’re saying I have an image and I have a caption, and so that will be wrapped in this figure element.

Because it’s within the figure element, it knows that it has a caption, and so doesn’t feel as though the image needs to be described in any way. It’s essentially like automatically adding null alt text to the image?

Steve: Yeah. The spec doesn’t say the image doesn’t need to be described. The spec’s quite clear in that it says that if there’s any chance at all that the image can be provided with an appropriate text alternative, it must be provided. It’s the reality is that quite often it’s not.

What’s happened in the past is that, quite often when it’s not, the software or authors put an empty alt tag on there. In doing that, they’re essentially hiding the image and the user’s not going to know there’s an image there at all, even if they wanted to interrogate it.

Sarah: Okay.

Steve: They won’t know, so they can’t even say to their mate, “Hey, there’s an image here. You’ve got a pair of eyes. Can you tell me what it is?” because they won’t know the image is there.

Previously, a way to provide the caption for an image was via the title attribute. Number of problems with this is the title attribute itself doesn’t carry the semantics of a caption, and also that the title attribute has various problems the way it’s implemented in browsers.

On mobile, you don’t see it. You can’t access the title attribute, anyway. Or, if you’re using a keyboard, you were hiding information.

With the use of the figure and figcaption pattern, what you’re doing is providing a programmatically associated, because the figure wraps around the image and the caption. You’re saying these things are associated, and you’re providing a visible label for the image, so the user knows something about the image.

Sarah: Nice.

Steve: I like it.

Sarah: [laughs] It sounds like a really elegant way to present the design pattern in a consistent way. Hopefully, it will lead to more accurate and descriptive and helpful descriptions of images, since it displays on the page.

Steve: That’s the hope. One of the issues is getting people to provide a text alternative, full stop— Maslow’s hierarchy of needs. [laughs] Get them to provide some text, and then make that text an appropriate text alternative, make it useful and meaningful. Each step is a little bit harder to make.

The thing is, at least quite often what’s happened in the past is that a text alternative will be provided using the alt attribute, where as a text alternative it will be what is, semantically, a caption. Now, we have a caption element that you can provide a caption for something.

It has a different meaning and it has a prescribed meaning that’s conveyed. For example, in Firefox, the figcaption element is exposed with a role of caption. That can be conveyed to the user, so they get told that this is a caption. This text is a caption. It’s not a text alternative or a replacement for the image.

Sarah: Oh, OK. That’s what I was thinking, that captions might have a really different function than a text alternative.

Steve: They do, in most circumstances. But, if people aren’t going to provide the text alternative, but they are going to provide a caption, at least the user knows that this is a caption and it’s a caption for something that’s not adequately described.

Sarah: It sounds like you can really look at the specifications. This is an instance where you’re looking at the real world and thinking about how things are implemented, the process for putting images on pages, and stuff like that.

When you’re working on specifications, do you talk a lot about the implications of changes on processes? In this case, we spend a lot of time in accessibility talking to people about creating good text alternatives for images.

This adds a little twist to that. Is that part of the spec development process, thinking about the cultural impacts of these things?

Steve: I think it definitely is. That’s the thing. A lot of the things that make it into HTML specification, other specifications, is that they look at the way authors use HTML in the world, they look at design patterns that are used, and say, “Let’s formalize that design pattern.”

The provision of a caption for an image is.…It’s not ubiquitous, but there’s a lot in the print media, academic textbooks, anything that has captions.

Newspapers and online news media have captions for images. There are a lot of circumstances where you have a visible piece of text that is associated with a particular image.

Previously, there was no way to say, “Hey, this is a caption for this image.” Now there is. It’s really formalizing design patterns or code structures that developers have been using.

Sarah: As someone who builds things and evaluates things that other people build, I find it really reassuring that the web standards people are looking at what’s happening and adapting those standards to support it. That’s great.

Steve: Yeah, that’s one of the things I’ve been particularly interested in. There have been big changes over the last 10 years in the way that the HTML specification, particularly, has been developed, how things get added, and what get described.

A large part of that has been a renewal of browser implementation information, ensuring that that is correct, and working closely with the browser vendors, and things like that. The authoring guidance, within the specification has not kept pace in the same rigor, and the real-world perspective hasn’t been applied to that.

One of the things that I’ve tried to do since I’ve been involved is get the information of the guidance and the specification to reflect both the constraints and the best practices that are in the real world.

To give you an example, one of the new features in HTML5—it’s new, it’s been around for a while now—is the placeholder attribute, which essentially allows you to define a piece of text that is displayed within a text-edit field or a text area in a control.

The thing that’s usually light gray and difficult to read, and then disappears. It’s a feature that a lot of people were doing via scripting.

You could use JavaScript to change the value of the control so it’d have that. It’s also a feature that’s available in other platforms, desktop platforms, et cetera, so it’s been added…but.

One of the things that I wanted to insure is that the advice around the use of that is clear that it should not be abused. It shouldn’t be used as a label in place of a visible label. We can’t always stop people doing that.

At the same time as not wanting to have it used as a visible label, one of things that’s important, and have worked and tested, is that in the absence of any other label text that it is exposed as a label through the accessibility APIs to assist technology users.

At least, again, a realistic point: they get some information. At the same time, in the specification, which echoes information that is provided by people like usability gurus like Nielsen Group, that you shouldn’t use a place holder as a replacement for a label.

It states that clearly in the specifications as author guidance, and states the reasons why. It’s problems with the color, that it disappears so it has an affect on users with cognitive impairments. There’s a whole litany of reasons why it’s not a good idea.

Those are clearly stated within the specification. It’s the thing that wasn’t there, but I have been working to get into the specification.

Even though the HTML specification is meant to be primarily for browser implementers, it’s also looked to, used, and is a valuable resource for HTML authors and developers, et cetera.

Sarah: I know I speak from many, many people in thanking you for bringing that perspective into the development of the specifications, and all of the hard work you and everyone else who’s involved in developing these specifications put in. Thanks very much for talking to us today.

Steve: Thank you.

Sarah: It’s been very informative and and enlightening.

Steve: I hope I haven’t gabbled on too much. I tend to gabble, especially when I’m sitting alone in my hallway talking to people.

Sarah: [laughs] It’s good gabbling. Let me put it that way.

Steve: Excellent. Thanks very much, Sarah. I had an enjoyable time speaking with you today.

Sarah: This has been Steve Faulkner sharing insights on how specifications like HTML5 and WAI-ARIA are there to help us in building a Web for everyone.

Many thanks to you for listening, and to our sponsors, UIE, Rosenfeld Media, the Paciello Group, and O’Reilly for making this podcast possible. Follow us @awebforeveryone on Twitter, that’s @awebforeveryone. Until next time.