January 10, 2012

Accessible HTML5 Forms – Required Inputs


HTML5 has added a number of new element attributes, including 12 attributes used when creating forms. These Common input element attributes include 2 new Boolean attributes, the required attribute and the readonly attribute. Recently a number of current browsers have implemented native support for the ‘required’ attribute, and so I thought it would be useful to examine this attribute in more detail.

Using the ‘required’ attribute

As its name would suggest, the required attribute is for form inputs that must be filled out before submitting the a form. It is important to note that there is no validation checking being performed (see GirlieMac!’s post on using CSS for light-weight pattern matching for form inputs), only that the form input will generate an error notification if the input is empty. I was curious if this error notification was being passed along to the Accessibility APIs by the different browsers that are currently supporting the attribute.

Adding the attribute to your form input is straight-forward: the current Draft specification states that:

The presence of a boolean attribute on an element represents the true value, and the absence of the attribute represents the false value. The values “true” and “false” are not allowed on boolean attributes. To represent a false value, the attribute has to be omitted altogether.

This means that unlike ARIA boolean attributes, which take the True or False values, the presence of the attribute automatically means that it’s value is true. We’ve had this type of attribute in HTML for almost as long as HTML has existed (<input type=”radio” id=”” value=”” checked>) so it should not be too confusing to most authors (and like XHTML1.1, the XHTML serialization of HTML5 requires the “attribute=attribute” pattern to be conforming).

Here’s the sample code:

<label for="first_name">First Name</label>
<input name="FirstName" type="text" 
       id="first_name" 
       required/>
<input type="submit"/>

Which results in the following example.




As you can see, attempting to submit an empty form will generate a “native” error message (go ahead, give it a try). But how accessible is that error message?

[Screen Captures: Firefox, Chrome and Opera browsers]

Using the above code sample, we ran a test page through a number of different browsers and browser/screen-reader combinations to get a sense of what would happen. While hardly an extensive test, the results were a little disappointing.

Test Results – Sample 1

Firefox 8, Opera 11.52, Chrome 15

on submit of empty field, “Please fill in this field” on-screen message displayed.

Safari 5.1.2, Internet Explorer 9

form submits even if input empty – no indication on screen that field is required

ChromeVox in Chrome 15

input NOT identified as “required”

NVDA 2011.3 and JAWS 13 in Firefox 8

input identified as “required”.

empty input identified as “invalid entry”.

on submit of empty field, “Alert Please fill in this field” read

NVDA 2011.3 and JAWS 13 in Internet Explorer 9

input NOT identified as “required”

VoiceOver in Safari 5.1.2 on Snow Leopard 10.6.8

input identified as “required”.

Color Contrast

On the bright side, the 3 instances of visual support for ‘required’ provides both a color based as well as text-based indication (error) for sighted users. A quick check of those colors and their color contrast (using Gez Lemon’s Luminosity Colour Contrast Ratio Analyser) produced the following results:

Firefox
The contrast ratio is: 3.13:1 – Passed at Level AA for large text only: If the text is large text (at least 18 point or 14 point bold), the luminosity contrast ratio is sufficient for the chosen colours (#FFFFFF and #FF5656). [This one is hard to evaluate accurately as it sits on the border between the "large text" and "small text" criteria, however given the amount of color present, I am inclined to believe that it passes the low-vision/color-blind pass/fail line.]
Chrome
The contrast ratio is: 1.56:1 – Fail: The luminosity contrast ratio is insufficient for the chosen colours (#FFFFFF and #F1CA7E)
Opera
The contrast ratio is: 14.51:1 – Passed at Level AAA: The luminosity contrast ratio is very good for the chosen colours (#F8CCCD and #000)

‘required’ versus ‘aria-required=”true”‘

The second test involved using only the aria-required=”true” attribute, and while the reporting to the various screen reader setups improved, we lose all of the built-in visual error functionality.

<label for="first_name">First Name</label>
<input name="FirstName" type="text" 
       id="first_name" 
       aria-required="true"/>
<input type="submit"/>

Test Results – Sample 2

Firefox 8, Opera 11.52, Chrome 15, Safari 5.1.2, Internet Explorer 9

form submits even if input empty; no indication that field is required

ChromeVox in Chrome 15

input identified as “required”

NVDA 2011.3 and JAWS 13 in Firefox 8

input identified as “required”

NVDA 2011.3 and JAWS 13 in Internet Explorer 9

input identified as “required”

VoiceOver in Safari 5.1.2 on Snow Leopard 10.6.8

input identified as “required”

According to the HTML to Platform Accessibility APIs Implementation Guide Working Draft, both the HTML5 attribute of ‘required’ and ‘aria-required=”true”‘ should map to the same Accessibility API State:

HTML5 attribute WAI-ARIA State or Property MSAA + UIA Express MSAA + IAccessible2 UIA ATK/AT-SPI Mac OS X
required aria-required=”true” Not mapped Expose IA2_STATE _REQUIRED Expose as IsrequiredForForm property Expose STATE_REQUIRED boolean AXRequired

When I first ran these tests, I postulated that perhaps aria-required should start to adopt the visual cues that the newer HTML5 ‘required’ was rendering in the browser – after all they *should* be synonymous with regard to user experience. I discussed this at some length with David Bolter (Mozilla Accessibility) who argued that adding this type of functionality to aria-required “late in the game” could actually cause author frustration, as legacy pages that already used aria-required would start to behave differently than what the author intended – perhaps even ruining existing visual design. It’s a fair point and Dave convinced me that I while my argument was logical, it was also inappropriate, and I agreed. He also stated that in Mozilla/Firefox both attributes did map out to the Accessibility API’s – something that my first two tests confirmed.

However at the time of these tests, only Firefox was doing this, with Chrome/Safari (WebKit), IE and Opera (on the Windows platform) not mapping the Accessibility state to the AAPI (although it appears that Safari on the Mac platform does, at least to VoiceOver). Hopefully this will change soon (and I will be filing a bug at WebKit and hope that IE 10 will catch this in time).

Wrapping It Up

The final test of course was to “double-up” both attributes on the form input, with the resulting code:

<label for="first_name">First Name</label>
<input name="FirstName" type="text" 
       id="first_name" 
       aria-required="true"
       required/>
<input type="submit"/>

Test Results – Sample 3

Firefox 8, Opera 11.52, Chrome 15

on submit of empty input, “Please fill in this field” on-screen message displayed — due to the @required attribute

Safari 5.1.2, Internet Explorer 9

form submits even if input empty — no visual indication that field is required

ChromeVox in Chrome 15

input announced as “required”

NVDA 2011.3 and JAWS 13 in Firefox 8

input identified (voiced) as “required” — not sure if @aria-required or @required takes precedence here

empty input identified as “invalid entry” — due to @required

on submit of empty field, “Alert Please fill in this field” read*

NVDA 2011.3 and JAWS 13 in Internet Explorer 9

input identified (voiced) as “required”

VoiceOver in Safari 5.1.2 on Snow Leopard 10.6.8

input identified (voiced) as “required” — not sure if @aria-required or @required takes precedence here, but will presume the aria-required.

(* I particularly like the fact that the Firefox test voices out the text of the visual error message – it is a nice touch.)

Conclusion

While we still don’t have a completely universal experience across all browsers, by doubling up the attributes we are ensured that the form input is as accessible as we can make it, while still taking advantage of the visual output that the ‘required’ attribute is starting to render. At this time then, the Best Practice is to still include both the aria-required and required attributes to your required form inputs.

Special thanks goes to Jason Kiss, who provided invaluable testing assistance for this article.

"Accessible HTML5 Forms - Required Inputs", out of 5 based on 11 ratings.

  1. #1 by Edmonton SEO on February 8, 2012 - 7:02 am

    and no matter what, safari was still the loser in all cases… I suppose I should be more surprised  :(

  2. #2 by hebdave on February 23, 2012 - 9:41 am

    I may be reading it wrong…did you accidentally swap the results for Chrome and Opera in the in the "Color Contrast" section?

    • #3 by John on February 23, 2012 - 6:49 pm

      Nope, the "gold" on white that surrounds the input field in Chrome does not provide sufficient contrast, whereas the "red" in Firefox (sort of) passes, ditto for the Opera example – see my comments there.

You must be logged in to post a comment. Here's Why.