Last week, I published an HTML 5 contact form WordPress plugin that used the HTML autofocus attribute to put the focus into the first form field.
Marc Aplet commented about the accessibility of doing that, for which I am very grateful as it made me think more deeply about it. Thanks to those on twitter who helped me further with my thinking.
Note that potential accessibility problems are not restricted to the HTML 5 use of autofocus; current JavaScript ways of doing it cause the same problems.
I believe that autofocussing into a form is a usability win for most people if the purpose of the page is that form—for example, the Google hompage. So, I wouldn’t autofocus into the search box or comment field on this page because the primary purpose of this page is discussing this article which requires prior reading. Most people are lurkers, not commenters, so it’s against usability to autofocus into the comment form. But a contact form is the primary purpose of a contact page, and it saves users a keystroke to put the caret into the first field—particularly usable for mobile phone users.
However, screenreader users find themselves dumped in the middle of a form, potentially without context (athough it’s always possible to tell the screenreader to repeat the title of the page, and we all give our pages useful titles, don’t we?).
Moreover, many forms have explanatory or introductory information preceeding them. My contact form does, although that’s somewhat flippant. A better example is Salford University’s Online Staff Directory Quick Search Page. The explanatory information is correctly outside the form element, as JAWS and (I think) Windows-Eye ignore any text that’s not inside legend and label elements when they’re in Forms mode.
What we need, then, is a way to associate some explanatory descriptive text that’s outside the form with the form itself (in a similar way that label and input are explicitly associated). Then a screenreader user could be alerted to the presence of this descriptive material by this programmatic association, and optionally choose to have it read out to them.
An accessible description may be computed by concatenating the text equivalents for nodes pointed to by an aria-describedby attribute on the current node.
So, I recoded the plugin (download it; it’s at your own risk etc) so that the descriptive matter is enclosed in a div id="form-description". The form element has the attribute aria-describedby="form-description" (because the description is for the whole form).
I don’t know if any screenreaders offer a keystroke to query this information yet (it’s over a year since I’ve been near a screenreader), but as the vendors have worked closely with the WAI-ARIA authors I imagine it won’t be long.
I also amended the plugin so that it has a belt-and-braces approach to the form fields that are required. In addition to the HTML 5 required attribute, I’ve added aria-required="true" as this is probably closer to implementation by screenreader vendors.
Because there are already two programmatic methods of indicating that a field is required, I’ve removed the traditional method of including an asterisk in the markup, as it’s possible to style the form fields with CSS—I’ve used a thick black border. (I tried to use attribute selectors to generate the string “required” immediately after the form field, but that gets surrounded by the field border rather than living outside it. The result is minging, even by this site’s low design standards.)
I’d been looking for ages for a decent plugin for WordPress that would give me a contact form that was easy to configure and didn’t use a CAPTCHA.
I eventually found Easy Contact which fulfilled those criteria. With a little jiggery-pokery, I hacked around the code so it produces an HTML 5 contact form featuring
autofocus to put the cursor in the first form field
in-browser validation of certain input types using input type="email" and input type="url"
the required attribute on fields that can’t be submitted blank (name, email, message and challenge question). I’ve styled these a foppish pink using input[required], textarea[required], while retaining the clunky asterisk-for-required-fields convention until screenreaders automatically tell users that a field is required
HTML 5 has the audio and video elements that conveniently allow an author to add multimedia to their pages in an intuitive way. The advantage to the consumer is that the files will play in the browser with no plugins, and the data will be in the browser and therefore can be manipulated with scripts.
To anyone who’s used to the horrors of YouTube-style embeds inside object monsters, the syntax is refreshing:
<video src="xxx.yyy" autoplay controls> <a href=""xxx.yyy"">Download this video</a> </video>
The autoplay attribute
autoplay is an attribute which makes the media play as soon as it can without prompting the user. This would be a problem for those who work in shared offices and who aren’t expecting depressing midi versions of classic rock songs to blare out when following a link, and would be a huge problem for people who rely on sound for understanding the Web, such as those using a screenreader or talklets, as the sound in a video would drown out all other content on the page.
This attribute can therefore cause annoyance or barrier and I wonder whether these negatives have been considered when the use cases for this attribute were deemed significant enough to merit its inclusion in the specification.
It’s not as if every video content provider is anxious to force their videos to play; some, such as YouTube, do but others, like Vimeo, don’t. Video sites catering to the gentleman’s leisure movie market (ahem) are similarly split: RedTube and YouPorn do begin automatically; Pornorama doesn’t. (See what I have to go through to research this stuff?!?!)
Update 8 May: I’m now reluctantly accepting that autoplay should stay because, as Simon Pieters points out
Removing the attribute will not make pages stop autoplaying video. Instead they will use script to make videos autoplay, and then it becomes harder for the user to prevent videos from autoplaying. (You could have a pref in the UA to disable autoplay.)
The controls attribute
controls is a boolean attribute which, if present, means that you want the browser to give stop/ play/ pause buttons etc. If it’s absent, it’s assumed that you are scripting your own controls. The controls spec says
User agents may make the following features available, however, even when the attribute is absent: … controls to affect playback of the media resource (e.g. play, pause, seeking, and volume controls), but such features should not interfere with the page’s normal rendering. For example, such features could be exposed in the media element’s context menu.
Given that autoplaying audio may significantly interfere with the page’s normal rendering in a screenreader, I think that the spec should say that user agents must provide a mechanism to mute or pause media. I’ve written to the working group to suggest this.
Update 8 May: So far, the response has been disappointing, with some pointing to the fact that the operating system has the ability to mute content. The trouble is that muting via the operating system will mute the screenreader as well as the autoplayed media. As a blind developer commented on twitter, “you’d be pretty unpopular if you did that to me”
4.9.7 Stop/Pause/Resume Multimedia: The user can stop, pause, and resume rendered audio and animation content (including video and animated images) that last three or more seconds at their default playback rate. (Level A)
Given that the HTML 5 spec already strays way out into accessibility territory by pronouncing on alt text, and is as much for implementors as for content authors, I think it should confirm what the draft UAAG says.
Accessibility of content
You’ll notice that in the code example above, the content of the video element is fallback content for browsers that can’t render the new element. In this case, it’s a link wher the user can get the video file to view offline. (This is exactly the same model as the content of an iframe in HTML 4).
Note: In particular, this content is not fallback content intended to address accessibility concerns. To make video content accessible to the blind, deaf, and those with other physical or cognitive disabilities, authors are expected to provide alternative media streams and/or to embed accessibility aids (such as caption or subtitle tracks) into their media streams.
This is radical stuff, but I think that it’s the right way to go. These days, content from one source is embedded into countless websites – see Flickr or YouTube. It’s wishful thinking to assume that everyone who wishes to syndicate the content will copy and paste accessibility information; we can see this in specs like oEmbed which is “a format for allowing an embedded representation of a URL on third party sites. The simple API allows a website to display embedded content (such as photos or videos) when a user posts a link to that resource” yet its authors don’t think that alternate text was worth including when embedding a picture.
So it’s better that the originator of the content writes/ provides the accessibility information just once and it’s accessible wherever it’s embedded through some kind of interface in the browser. (I expected the spec for controls to say that, whether or not the attribute is present, the user agent must provide a mechanism for accessing the embedded alternative content, but it is silent on this.)
So philosophically, I support the write-once-carry-everywhere model for media accessibility. But how would I author it? I’ve made a few videos with Windows Movie Maker that I’ve uploaded to YouTube, and published my songs in the (proprietary) mp3 format, but I have no idea which formats carry synchronised captioning or transcription information within them, or what authoring tools I can use.
Are there any?
(Related plug: under the banner of standards.next, I’m talking about HTML 5 at a free meet-up in London on —the day after @media—with Molly, Remy Sharp, Dean Edwards and hopefully others. Details.)
If you asked most people outside India for their ideas about the country, they’d probably say “fabulous history, ancient glorious culture, techologically third world”.
But here’s two technological things I saw during my recent university tour that we could learn immediately from India. The first is the complete abolition of plastic bags in the capital, Delhi:
The second is this full-page magazine advert that reads
India.gov.in is now accessible to visually challenged. Yet another step to make the national portal citizen-centric in its true sense. Physically challenged friendly, mobile devides friendly, senior citizen friendly, assistive technology friendly.
I’m not a screenreader expert, so haven’t verified its usability with assistive technology, but I would be delighted to see such publicly-expressed commitment from my “first-world” government for user-centric inclusive design. Compare this with the Department of Trade and Industry fiasco, for example.
