The premise

The base for my talk is my third easy ARIA tip, where I enhanced a form with some basic local form validation to help users fill it out and avoid errors upon submission. If you are not or no longer familiar with what I did there, stop reading here and go read that post again as a recap. If you are caught up, let’s move on!

From WAI-ARIA to HTML5

Since then, a lot of time has passed, and we’re now much better equipped with native markup magic that HTML5 supplies us. Thankfully, Firefox and also other browsers implement most, if not all, these features now, so we can move ahead with our changes. To remind you, WAI-ARIA is there to enhance, not substitute, native markup, so whereever possible, we should use native markup when available. These changes are:

1. Strip all JavaScript: Let’s start clean and see how far the new native markup stuff gets us!
2. Throw out all aria-required="true" instances and replace them with the HTML5 required attribute. This gives us automatic flagging of a required field not only via accessibility APIs, but also through visual indicators. Also, a required field is automatically flagged as invalid if it is empty.
3. For the field ‘name’, add a pattern attribute containing a regular expression that defines a valid name consist of some characters, one space, and some more characters. This will cover most cases, and if you’d like something more complex, consider me giving you some homework.
4. The field “email” gets the type “email”, the field “website” gets the type “url” set. This gives us proper validation of e-mail addresses and URLs respectively right upon entry. Moreover, on mobile devices with a virtual keyboard, the most common extra keys are usually provided right out of the box.

In addition, for a better error message, I am using the non-standard x-moz-errormessage attribute on the “name” field to tell users that the name was entered wrong rather than the standard “patterns don’t match” error message the browsers usually throw at users in the instance of them having entered a wrong value.

In addition, the name field contains (already in the ARIA example) a title attribute that tells users that a name must consist of at least two words.

Filling out this form now gives us validation upon submission. Firefox sets focus back to any invalid field it finds when users press the “submit” button. In addition, an error message is displayed describing the problem.

…and back

Our original example, however, was better in that it provided validation right at the point when an entry lost focus. Since this is a dynamically created alert box that is not yet a native HTML5 element, we have to resort to WAI-ARIA again to make this work the same, but using the HTML5 validation benefits. So, let’s enhance our example:

1. Bring back the first two functions from the original ARIA version unchanged. These remove any existing alert box, and they create a new alert with the given message.
2. Adjust the function that is called in the onblur handler of the “name” and “email” fields (see below):
   1. First, we have to adjust the function name to something that doesn’t clash with a reserved word. I used testIfEntryIsValid.
   2. Now, get rid of the search string and error message parameters. These are no longer needed because the validation is done by the browser, and we simply use the HTML5 form constraints API to ask the browser for the relevant info. Also, the browser provides us with the appropriate error message, so no need to generate one ourselves here.
   3. In the if clause, simply ask if the call to the checkValidity() method of the element we obtained in the line above gives us a “true” or “false” result. If true, simply remove the old alert. If false, create an alert and use the element’s validationMessage property as the message parameter. The browser will handle the rest for us.
   4. Remove the lines that set aria-invalid. These are no longer needed, since the browser’s constraint validation will provide the invalid or valid states automatically.
3. For the “name” and “email” fields, add back onblur handlers pointing to the above function and simply pass in the field’s ID.

Testing this example, it shows that we’ve got our original functionality back. In addition, if we ignore the intermediate error messages, the browser’s validation mechanism will throw us back to any of the wrongly filled out fields upon a submission attempt. Note that not all browsers do this last step. Safari on the Mac, for example, will submit the form even if it contains invalid entries.

In summary

The new version of our form is much improved over the version we had originally. It still contains some WAI-ARIA where it makes sense, since there is no native HTML5 alert box yet. But the rest is HTML5. The JavaScript code is a bit less bloated since we don’t have to do our own validation any more, and we benefit from all the builtin constraint validation mechanisms.

Feedback is welcome! But before you throw things at me for my sloppy JavaScript, please keep in mind that this is just a proof of concept. If you would like to re-use this technique, I encourage you to put your best knowledge to use and put in better handling of events or such, appropriate for your web application.

The example pages can be found (in English and German) at this address. Happy hacking!

This means that web devs can use the progress element in web applications, and we will now no longer expose the alternative text enclosed in the opening and closing tags, but the actual visual representation of a progress meter. The accessible object for the progress meter will expose the AccessibleValue interface for all relevant platforms (e. g. ATK and IAccessible2), so that assistive technologies can query for not only the value string but also the float values for:

• the current value
• the minimum (always 0)
• the maximum (if not specified, the default is 1 as in the specification)

By default, NVDA will expose the current percentage as you can test in this example with a current version of NVDA.

Note that there were no changes required on NVDA’s side to support this. So if your screen reader currently supports WAI-ARIA progress meter elements, and the screen reader does not do any funky stuff with their own HTML parsing here, this should just work.

Another note: While we were here, we also fixed a few things regarding XUL:progressmeter elements that were buggy in the past, but were not really uncovered until now. The user visible impact will be minimal for this, but for our code this was definitely benefitial, as we’re now dealing with the proper maximum value for xul:progressmeter elements, which differs from the default max for html:progress.

Landmark elements mapped to WAI-ARIA landmark roles

We are mapping the following HTML5 landmark elements to accessibles with WAI-ARIA landmark role semantics:

In a second small patch landing the next few days, we will also map the html:aside element to the “complementary” role. This was a small oversight on our part in the first patch.

Both NVDA and Orca will pick these changes up without any additional action required on their parts. Other screen readers will hopefully implement or pick up the support ASAP so web authors can use these new elements without having to worry about support or lack thereof.

The placeholder attribute

This attribute can be used on form elements to predefine text that disappears as soon as the field gets focus. It#s a visual indication of what is expected in the field. If, and only if, the field has no label otherwise, this placeholder text will be used to generate the AccessibleName, the name the screen reader speaks for the field when it gains focus. If the field has a label provided by the label element or an ARIA construct, the placeholder text will be ignored.

Proper events being generated when required/invalid/disabled states change

For a few weeks now, we have had support for the disabled, required attributes and the invalid state evaluation of patterns. Now, if any of these conditions change, we now generate the proper StateChange events to notify screen readers and other assistive technologies.

The first stage is complete: Firefox 3.2a1pre as of Wednesday’s nightly will expose such indeterminate checkboxes as what we internally call STATE_MIXED. There are still two work items left as far as we can see:

1. Expose an action name for a checkbox that is in this indeterminate state.
2. Make sure we fire STATECHANGE events for STATE_MIXED.

For action item 1, I’d like to call out to you guys to offer suggestions on what this action name should be. My initial idea is “toggle”. The reason is that we will never know whether the next state after clicking will be fully checked or fully unchecked. That always depends on the web site’s author to decide. That’s why I first thought of this neutral name.

Anybody got any better ideas, or even a suggestion derived from other such indeterminate, or tristate, checkboxes from operating systems? Post your ideas here or comment on the bug.