Recently, Deque offered a preview webinar of Worldspace Sync which illustrated how:

• Managers can monitor multiple websites and applications for accessibility (Section 508 and the WCAG 2.0 Standards)
• Worldspace Sync can navigate your applications following recorded use cases to analyze your site beyond the login screen
• Developers and QA can utilize Worldspace Sync and FireEyes to analyze content during the entire lifecycle.

If you are an ACE member and would like to be considered for the pilot program, please email our VP of Product Marketing. Those chosen for the pilot will have the opportunity to use Worldspace Sync to evaluate 3 URLs for two weeks. After the test period, Deque will schedule a follow up meeting to get suggestions and feedback. This is a fantastic opportunity for developers in the accessibility field!

To view the pre-recorded Worldspace Sync webinar, click here.

*Although we welcome accessibility developers from every area to join ACE, you must be an independent accessibility consultant to be chosen for the pilot program.

If you’d like to lean more about Deque and the services we offer, please contact us.

In the second video in our Multimedia and Accessibility series, Glenda Sims discusses the different caption types for online media.

Please go to deque.com/cvaa to request our white paper, and learn more about how the CVAA affects online audiovisual content distributers.

Video Transcript:

00:24

When we’re talking about making video content accessible, there are actually two pieces.

00:31

The more commonly understood piece is captions: that’s where we’re trying to make sure that

00:37

the audio content of the video is accessible to people who cannot hear. That means that

00:43

all dialog and important sounds are turned into a written caption or a written transcript

00:50

that is then time-synced to the video. It’s also valuable that – when adding the caption

00:58

that you also make the pure transcript, in a text format, available. While this is

01:05

not a technical requirement – to make the transcript by itself accessible and available

01:11

to people – I would highly recommend it. If you’ve gone to the effort to add a time-sync

01:17

caption to your video that means that you have a transcript file available. Why is the

01:23

transcript file useful? Because for people who may need to slow down and read that content

01:30

or to reread it or who are easily distracted by, perhaps, what’s happening visually on

01:35

the screen; they can focus on that text transcript and sometimes get better access to the information.

01:43

So I think of it as a double bonus. The additional piece that a lot of people are not aware of

01:49

for making video content accessible is called “audio description,” and this accessibility

01:56

is for a whole different type of user disability; and that is for people who cannot see. What

02:03

we’re trying to do is describe what is important happening visually in the video to make sure

02:11

that they get all that content. In the example of this video, you wouldn’t need very much

02:19

audio description because what we’re dealing with here is a video of me talking directly

02:25

to the camera and there’s nothing critical being shown. There’s no graph, there’s no

02:31

demonstration where I’m saying, “And look here, you can obviously see what’s occurring

02:37
in this demo.” If there were that type of element happening, you would need an audio

02:44

description. My best way of describing audio description is: imagine you’re at a movie

02:51

and you’re blind. Imagine you’re in a horror movie, and you’re blind, and you’re only listening

02:57

to the dialog. And, for those who can see, there’s a shadow on the wall of someone holding

03:06

a gun. This is a really important visual element that would need to be audio described to the user.

ARIA’s role=”group” and role=“radiogroup” can be used to group form controls to yield results that are comparable to HTML’s FIELDSET – LEGEND elements. Testing shows that when these roles are set on container elements (like div, td, etc.) and labeled with other ARIA attributes like aria-labelledby or aria-label, the method offers a viable alternative to that is supported by browsers like Firefox and Internet Explorer and screen reading software JAWS for Windows and NVDA.

Note: My testing was done using Firefox 11, IE9, IE 8, JAWS 13, JAWS 12 and NVDA 2011.2.

The FIELDSET element by default draws a border around the form controls it holds. HTML does this deliberately as an accessibility feature for users who need such a visual cue. Some developers suppress this border via CSS or avoid using the fieldset-legend elements when it”obstructs” visual design, for instance, when a form is within a table. ARIA’s role=group / radiogroup does not create a border; yet it offers developers the ability to convey grouping of related form controls via markup and any visual styling mechanism of their choosing (color, font, border or any other) when they find the fieldset-legend inconvenient in some situations.

Here is a sample file created for this test. While the main objective was to test out role=group / radiogroup and compare it against fieldset-legend, I also reviewed latest support a few other ARIA attributes and the HTML 5 “required” attribute and have documented the observations as part of this exercise.

Description of the sample file:

The file contains 3 forms: a search form, a partial registration form and a partial credit card application form.

1. Two landmarks, role=search and role=main are used; the latter has an aria-label=”registration form”. (The main section contains 2 forms; aria-label text is merely illustrative).
2. The registration form has identical sets of fields for first and second applicants. The fields for first applicant are grouped using fieldset/legend method; role=group is used for the fields under second applicant.
3. Role=group is used for SSN fields and date of birth fields within the form controls under each applicant.
4. A fieldset-legend is used for gender radio buttons for the first applicant; role=radiogroup is used for gender radio buttons for second applicant.
5. The HTML 5 “required” attribute and aria-required=true have been used on name and date of birth fields. The SSN fields use only the ARIA method. The gender radio buttons for the first applicant relies on the legend element (asterisk) and uses aria-required for the second applicant’s gender radio buttons. Except for the gender buttons within a fieldset, an asterisk is alsoplaced next to every field to convey that it is required input; but the asterisk is deliberately not programatically associated with the form controls.
6. The Credit card application is within a layout table with role=presentation.
7. The credit card type radio buttons are grouped using role=radiogroup.
8. All group and radiogroup roles are labeled with aria-labelledby.
9. The search field and the 3 parts of SSN fields use the title attribute to label the fields; explicit label association using for-id method is used for the rest.
10. The visible instructional text for date of birth placed at the end of the registration form is linked with the The DOB fields use aria-describedby to associate the tip about date format. The tip is visible text near the end of the registration form.

Note: The sample file does not use any presentation styles to demarcate groups of form controls.

Summary of Observations

[*]: This is not an accessibility feature. Only intended to convey what a user experiences when group / section change is encountered and differences in user agent behavior.

[$]: This is a difference in behavior between JAWS 12 and JAWS 13.

Conclusion:

As one might expect there are nuances in behavior across browsers and screen readers tested. Yet:

• The roles “group” and “radiogroup” are well supported and may be used to group form controls in situations where one might use HTML’s fieldset – legend elements. It is advisable to include some visual cue via CSS to convey grouping too.
• The other ARIA attributes also are well supported: aria-label, aria-labelledby, aria-describedby, aria-required, role=”presentation”, and the landmark roles. (Note: I have not used aria-labelled by or aria-label to associate text labels (other than group labels) with form controls but have relied on the robust LABEL element and not so robust title attribute for this).

Created by Sailesh Panchang, Deque Systems | May 14, 2012

If you’d like to lean more about Deque and the services we offer, please contact us.

With all of the focus on the CVAA, we wanted to shed some light on the Act, and how it impacts you, as well as show how accessible multimedia affects those living with a disability. Enjoy the first video in our series Multimedia & Accessibility, with Glenda Sims, accessibility evangelist and a Senior Accessibility Consultant for Deque.

Please go to deque.com/cvaa to request our white paper, and learn more about how the CVAA affects online audiovisual content distributers.

Video Transcript:

00:24

When I first, FIRST started using the Web the majority of the content was text and pictures.

00:29

It was a long time ago. But today’s web is full of rich media, especially video, and

00:38

as we are looking at the accessibility of video we have to keep two things in mind:

00:44

not only does the video need to be accessible with captioning and audio description, but

00:49

the players need to be accessible as well. What do I mean by an accessible video player?

00:55

I mean a player that can be used by a person who is using a keyboard alone, who may not

01:02

be able to use a mouse; and also a video player that is accessible to screen-reader users

01:08

so that people who are visually impaired can actually control, turn the video on and off,

01:16

and adjust the volume. By making these components accessible we give equal access to all the

01:22

important information that we’re now distributing via multimedia on our websites.

If you’d like to lean more about Deque and the services we offer, please contact us.

Senior Accessibility Consultant, Glenda Sims

What do you do at Deque and how long have you been here?
I’m a Senior Accessibility Consultant at Deque where I get to share my expertise and passion for the open web with government, education, and companies that range from small business to Fortune 500. I do hands on web accessibility assessments, develop accessibility roadmaps and strategies, and consult with developers and designers during sprints.

How did you find Deque (or how did Deque find you)?
I first heard of Deque from Jim Thatcher, and as soon as I met the team I was blown away by their drive, focus, and enthusiasm for creating truly revolutionary accessibility testing tools.

What is your favorite thing about working at Deque?
My work at Deque is so deeply meaningful. I’m working with organizations who are ready to tackle accessibility. It is truly refreshing and energizing to work with developers, designers, quality assurance testers, project managers, and leaders who are committed to designing, building, refining, and maintaining an accessible web presence. And I’d be remiss if I didn’t say that I work with some of the smartest, most intellectually stimulating, creative, and caring people on the planet.

What interests you about accessibility?
My personal mantra is based on the spirit of the W3C Mission statement, “Web for everyone. Web on everything.” When I first got into accessibility, in the late 90′s, I originally did it because it was the right thing to do for people with disabilities. About a decade into the field, I realized….Oh! Accessibility is the right thing to do for humanity. I believe, with all my heart, that accessibility takes us to the next level of universal design. Design so thoughtful it works for everyone. Accessibility is a design challenge…and I’m always looking for that sweet spot….where the creative solution for the accessibility challenge is truly a better design for all people.

What current topic/debate in accessibility that has caught your eye?
I’m very interested in seeing an international society for web accessibility professionals. I think the world and the web can benefit from a strong network of experts and a globally endorsed set of educational resources. Read what colleagues of mine are saying at: Friends of the ATIA Newsletter – The Need for an Accessibility Profession

Desert Island picks: one album (music), one movie, one book, and one luxury item (assume you have food, water, shelter, and a radio – no boats/planes/etc. allowed).  

If you’d like to lean more about Deque and the services we offer, please contact us.

Today is Global Accessibility Awareness Day, and in honor of the occasion I decided to attempt going mouse-free for an hour.

I admit I went into this challenge a little overconfident; I mean, I’ve got a pretty good vocabulary of keyboard shortcuts, I’m reasonably tech-savvy - it may take longer than navigating with a mouse, but I figured it would be a stimulating challenge and I might come away with some more keyboard tricks in my bag.

I was mistaken.

After about 30 minutes of researching keyboard navigation,  I realized I was going to have to have to narrow the scope of this challenge if I wanted to complete my mouse-free hour and write a blog post before the end of the day: I would limit myself to web activities (in my Google Chrome browser), I would not use any of keyboard navigation plug-in applications, and I set myself a series of five every-day, mundane tasks to complete.

1. Check my email, and compose and send an email.

2. Check out my blog feed and share any interesting new posts (via the feed’s Share feature).

3. Watch a YouTube video.

4. Purchase an audiobook and send it to my eReader.

5. Check the time for the movie I’m attending tonight.

I printed off Chrome’s 4-page list of keyboard shortcuts and, with trepidation, turned off my mouse.

Checking my email wasn’t so bad.  It’s easy enough to open a tab and select my email from my bookmarks. Pro-tip: once you’ve tabbed to your bookmark folders, you have to hit space-bar to see the listed sites – not enter, not down-arrow, not any of the other arrows, and not enter 10 times in rapid succession.  The tabbing order for my mail client (Gmail) was pretty intuitive, though tabbing does get tedious after a while, and the only hiccup in sending an email was not realizing that the Send button at the bottom is in the tabbing order long before the top one.  So far, so good.

The blog feed was not so simple.  I’m a Google Reader user, and I typically navigate to Reader from my G+ feed.  This may not be a problem for most people – I am told there are only about 12 people who use G+ that aren’t Google employees  - but it was a big problem for me.  When you open G+, the tabbing starts with your G+ feed: you have to tab through your feed entries before you can tab to the other page components, but the G+ feed uses infinite scrolling.  That’s right, I would have had to tab through every entry in my G+ feed before I could reach the menu I needed to access Reader.  I immediately closed the tab in horror, opened a new one, and typed “google reader” in the address bar.  Much better.  Checking my blog feed was easily done; however, when I found a link I liked I had to tab through every link in every previous post in my feed to get to it and open the link.  And the Share button was not one of the tab destinations when tabbing through the posts (infinite scrolling is also a feature of Reader), so I gave up on my assignment to share a post.

It was easy enough to make my way to a desired YouTube video (an episode of David Mitchell’s Soapbox was my destination), but I couldn’t figure out how to skip ads – how do you tab a button that’s on the video?  And I couldn’t seem to tab to the controls under the video, or at least I couldn’t tab there before I got frustrated and decided not to try out fullscreen.  It is possible that I just didn’t realize when I’d made it to the controls – there were points when the selection box disappeared entirely.  I could have been anywhere.

By far the worst experience was trying to purchase an audiobook (from a major audiobook seller) without a mouse.  I could only see what I’d selected about 5% of the time and selecting entries returned in my searches was apparently impossible.  I couldn’t even select audiobooks presented on their home page.  After 3 or 4 tries, I gave up.  Checking on the movie time restored some of my faith in humanity.  The only incident when navigating to my desired film and theatre was having to tab through all the movies in a drop-down list without the benefit of having the list actually drop down so I could see what I was tabbing through.  I only realized what was happening by watching the information flashing at the bottom of my browser window.

These tasks, which would normally take about 15-20 minutes to complete, took nearly an hour.  And 3 minutes before my clock ran out I accidentally hit Ctrl+Q and closed my browser.  I didn’t know how to reopen my browser from the desktop, so that was the end of my mouse-free challenge.  I was only able to totally complete 2 of the 5 tasks I set for myself  - I’d say about a 60% success rate overall.  I can’t imagine what it would have been like to do something more complicated – pay a bill, buy a pair of shoes, catch up on my Hulu queue.  At least I could see everything on my monitor; a lot of users who have to navigate entirely via keyboard can’t.

Using technology without all of your faculties is hard, not to mention frustrating.  It’s a shame that a tool as amazing as the internet is inaccessible to so many users.

You can learn more about Global Accessibility Awareness Day at the Global Accessibility Awareness Day website.

If you’d like to lean more about Deque and the services we offer, please contact us.

WAI-ARIA is WAY COOL! In part two of the three-part series on accessible form validation and usability enhancements we’re going to use WAI-ARIA (Web Accessibility Initiative – Accessible Rich Internet Applications) to communicate information to screen reader users only.

Demo Form with HTML5 & WAI-ARIA Validation

Limitations of ARIA

ARIA only works on some of the latest screen readers and browsers. It does not work with all AT (Assistive Technologies). There is no support for speech recognition software such as Dragon NaturallySpeaking. Window-Eyes and ZoomText have limited support.

Derek Featherstone (@feather) has an excellent blog post on A List Apart titled ARIA and Progressive Enhancement where he documents ARIA support on Window Eyes & ZoomText. There are also good ARIA coding techniques and live form examples.

Enhancing Forms with ARIA

Sometimes developers use color alone to alert users that required fields are not filled. DON’T DO THIS! What you should do to indicate a required field is to place text in the label that says so. Many times you see a red * or the text (required) placed in the label. This is the recommended approach. Other recommendations involve creating a star graphic and placing it in the label with alt=”Required”. This works as well but it is buggy in OS X Lion where the alt attribute is not announced in a label.

By default NVDA will not speak an asterisk * as “star”. VoiceOver & JAWS both say “star”. NVDA users can adjust their Symbol Pronunciation settings to force * to be spoken by setting the Level to “some” but not all users are aware of this feature and will usually be running on default settings. By placing the aria-required=”true” attribute on all required fields NVDA will now announce they are required at the default settings. VoiceOver and JAWS will speak the star and the required attribute.

aria-required=”true”

The easiest enhancement is to add the aria-required=”true” attribute to all required fields in your form.

Screenshot

Below is a screenshot of the VoiceOver Caption Panel on OS X Lion which provides an excellent way to visualize ARIA/screen reader output if you’re deaf or hard of hearing or don’t want to annoy others in the room with your computer speaking everything out loud. I think it would be cool if iOS could do this as well!

Don’t worry about having the HTML5 required attribute and the aria-required=”true” attribute and causing repetition. All the screen readers I’ve tested only speak required once. Here aria-required is your fallback for browsers who do not support HTML5 like Internet Explorer. This way screen readers which support ARIA will speak the ARIA attribute when used with IE and ignore the HTML5 attribute.

ARIA Techniques for WCAG 2.0

ARIA2: Identifying required fields with the aria-required property

WAI-ARIA 1.0 Authoring Practices

Use aria-invalid and aria-required To Improve Access to Forms

Other ARIAs for Consideration

aria-invalid=”true” role=”alert”

Marco Zehe (@MarcoInEnglish) from Mozilla wrote a post called Easy ARIA tip #3: aria-invalid and role “alert” which recommends setting aria-invalid=”true” on fields with errors and creating a div with a role=”alert” to hold the error messages. Since this involves JavaScript to inject the ARIA attributes I’ll save this experiment for the next post.

aria-describedby

How do assistive technology users navigate forms? Do they tab through the inputs like I do to quickly fill the fields out with the keyboard? Do they use their arrow keys to go down through the fields and the text between the fields? Or do they use other screen reader shortcuts like the F key for form fields?

In most of my experience testing forms and receiving feedback from others in the industry, tabbing through forms is the most popular interaction method. This is why I recommend placing all instructions and errors in the labels. As the user tabs through they would hear all instructions spoken by a screen reader.

What if the instructions to complete a form field are just really long and you’d rather not include them all in the field’s label? Well if the user’s AT & Browser have support for ARIA you could instead include those long instructions above or below the field and then point to them with the aria-describedby attribute causing the supported screen reader to speak those instructions after the label.

ARIA Techniques for WCAG 2.0

ARIA1: Using the aria-describedby property to provide a descriptive label for input controls

aria-labelledby

If you are using explicit labels and aria-describedby then there should not be many reasons to need to use aria-labelledby on form fields. Marco Zehe has a good example of where aria-labelledby could be useful on forms. Easy ARIA tip #2: aria-labelledby and aria-describedby. The example illustrates a problem where a text input field might be placed in the middle of a sentence but it needs to be labelled by the first part of the sentence, the input’s value itself, and the final part of the sentence.

aria-label

aria-label is meant to be used in cases where a text label is not visible on the screen and a visual tooltip is not desired like when using the title attribute.

In the second version of the ARIA demo form I’ve used the aria-describedby attribute as a replacement for placing input formatting instructions in the label and positioning it below the form field with CSS. Instead of using visually hidden labels with CSS I used the aria-label attribute to label inputs that do not need a visual label like when a phone number is split into three fields.

Final Thoughts on These Other ARIAs

In these other ARIAs for consideration I’ve only been talking about their usage on forms, however, they are many times meant to be used to label and describe “desktop-like” HTML widgets that have been built using non-form tags such as divs and list tags. For more information read: Using the aria-labelledby attribute & Using the aria-describedby attribute from the Mozilla Developer Network.

Demo Form with HTML5 & WAI-ARIA Validation

Demo Form 2 with HTML5 & WAI-ARIA Validation

Last Steps – Add jQuery Validation

In the last blog post we’ll add the final layer of client-side form validation using the jQuery Validation Plugin and tweaking its settings to maximize the accessibility and usability of our form for all users on all devices. It will even work for IE 6!

Comments? Questions?

So what do you think about these WAI-ARIA form enhancements? Would you take the approach a different way?

Do you think all instructions, cues, input formatting requirements should be placed in the label? Or would that make the labels too big so longer instructions should be in adjacent text and pointed to with aria-describedby?

Would you rather just add tabindex=”0″ to the instructions to put them in the default tab order and keep the labels as small as possible? Are you a big fan of the title attribute and would rather put everything in there instead of using ARIA?

A lot of forms accessibility practices are up for interpretation and debate so I’d love to hear your thoughts and feedback in the comments!

Let me know if you have any suggestions for improvement or find any mistakes. Leave a comment below or send me a message on Twitter @pauljadam.

If you’d like to lean more about Deque and the services we offer, please contact us.

Marko Vouriheimo, known on the stage as SignMark, signs while his MC rhymes. “Since 2006, he has performed in 35 countries and even finished second on a Finnish show similar to American Idol.  He has been an inspiration to the deaf community, but he wants to open everyone’s eyes.”

Note: unfortunately, the video is not captioned, but you can read the article here.

If you’d like to lean more about Deque and the services we offer, please contact us.

Deque: Could you give us a brief description of Australian Web Awards?

Helen: The Australian Web Awards seek to showcase Australian-grown talent by recognising outstanding web design and development by businesses and individuals to the Australian Web Industry.

What criteria are the Australian Web Awards based on?
The awards are based on 2 stages. The 1st stage is based on validation criteria. The criteria for this is:

• W3C mark-up validation using W3Clove.org
• W3C CSS validation
• Link checking
• A first pass Accessibility check using WAVE
• web page load testing using webpagetest.org

The errors and warnings from the criteria above are given a score and the combined total gives us an idea of what sites should go onto the second stage. This is so the judges from industry who do the 2nd stage testing are only judging the best compliant websites.
The 2nd Stage criteria are:

• Accessibility – a closer look using FireEyes
• Design – what it looks like
• UX – does the user interface provide a good to excellent user experience, easy to use, easy to navigate?
• Content – quality content, images, order of content, use of SEO
• Fitness for purpose – does the site design fit the content model, i.e. e-commerce – shopping cart?
• Credibility and validity – having the legal stuff like Terms & Conditions, privacy policy, copyright, etc.
• Development – this is about the code development and using best practice techniques
• Mobile – how does the site view on a mobile device? Has it had mobile devices taken into account for its design?

There are Three judges for each category: one design oriented judge, one development oriented judge, and one everyday user judge.

How did you develop these criteria?
The criteria were developed over many years, first as the WA Web Awards and then as the Australian web awards. Each year we take feedback from judges and the web development community on the judging process and criteria, which we then use through our quality improvement  program for the next year’s awards. The criteria is also based on what the web development community at large sees as important, in addition to compliance to standards and best practices.

What inspired you and your colleagues to start the Australian Web Awards?
The Australian Web Industry Association use to hold an awards program for Western Australia only. This happened from 2004-2008. The main impetus for the awards was to reward developers and designers who were doing excellent work and apply best practice as well as being standards compliant. The awards were a way of encouraging the web development community to embrace best practice as well as standards compliancy. In 2007 we started getting requests for entry from Eastern States developers, so we took some time to see how we could expand and have all web designers and developers from Australia enter the awards. This finally happened in 2009 and it is truly a competition of best practice and standards. Our next goal is to make a web development community award for accessibility compliance just as we did with best practice and standards compliancy.

Who are some previous winners of these awards?
A list of our finalists and winners from the last 3 years is available at: http://www.webawards.com.au/finalists/. In 2012 we introduced a special category of awards which focussed on specific criteria. That is: Best Overall HTML, Best Overall Visual Design, Best Overall Accessibility, and Best Overall User Experience. One of our finalists for Best Visual Design (Big Stories, Small Towns http://bigstories.com.au Freerange Future (SA)) also entered in SXSW awards and won the Best Community Site award.

How did you find the Deque tool set?
Our Judging Panel chair from 2012, Gary Barber, uses it in his work and suggested we use this tool in our judging process for the more in depth accessibility judging.

How does FireEyes contribute to your judging process?  
During the second stage, a more comprehensive accessibility assessment is undertaken after the initial WAVE report. We typically concentrate on main purpose of the site instead of incidental pages. So for an e-commerce site we look at the catalogue and shopping cart process in depth, and for a business we look at the site overall but concentrate on their offerings and products as well as contact page.

If you’d like to lean more about Deque and the services we offer, please contact us.

Connecting labels to inputs is easy! But what about required fields, error messages, and keyboard focus?

In this three part blog series we’ll learn to make accessible forms with HTML5, WAI-ARIA, and jQuery Validation. Our strategy will be to first try validation with HTML5 in the latest browsers that support these form attributes, then we will use WAI-ARIA which works with the latest screen readers, and finally for the folks who just can’t upgrade we’ll add the jQuery Validation plugin so even IE6 users can accessibly submit forms.

Demo Form with HTML5 Validation

Basics

The basics of form accessibility are sometimes overlooked so I’ll point them out for review.

Every. Single. Field. Needs. A. Label.

Easy enough to remember? The only bulletproof way to ensure an accessible form field is to provide an explicitly connected label using the for and id attributes.

A quick test for an explicit label is to click on the label’s text with your mouse and if focus goes into the input then they are connected. This increases the click target size and really helps everyone click those tiny checkboxes and radio buttons.

Technique for WCAG 2.0 – Success Criteria 1.1.1 (Non-text Content), 1.3.1 (Info and Relationships), 3.3.2 (Labels or Instructions), and 4.1.2 (Name, Role, Value)

H44: Using label elements to associate text labels with form controls

HTML

<label for="fname">First Name *</label>
<input required type="text" name="fname" id="fname">

Output

First Name *

Do this for every single field! If you don’t want to see the label then hide it off screen with CSS.

Radio Buttons & Checkboxes Need a Fieldset & Legend

HTML

<fieldset>
<legend>Gender *</legend>
  <input type="radio" name="gender" value="male" id="male">
  <label for="male">Male</label>
  <input type="radio" name="gender" value="female" id="female">
  <label for="female">Female</label>
</fieldset>

Output

Technique for WCAG 2.0 – Success Criteria 1.3.1 (Info and Relationships) and 3.3.2 (Labels or Instructions)

H71: Providing a description for groups of form controls using fieldset and legend elements

Are All Instructions Spoken?

Are input formats spoken? Did you indicate the correct format for dates, phone numbers, etc.? Again, the best way to communicate form instructions to screen readers is to place them in the label.

HTML

<label for="bday">Birthday * MM/DD/YYYY</label>
<input type="text" name="bday" id="bday">

Output

Birthday * MM/DD/YYYY

Technique for WCAG 2.0 – Success Criteria 3.3.2 (Labels or Instructions) and 3.3.5 (Help)

G89: Providing expected data format and example

Required Fields

No one enjoys filling out forms! If you want to get useful data and not scare your users away then only require the least amount of fields as is necessary. Indicate the field is required by placing a red * in the label or the text (required).

Technique for WCAG 2.0 – Success Criterion 3.3.2 (Labels or Instructions)

H90: Indicating required form controls using label or legend

Error Messages

Help users out by providing useful error messages and suggestions to correct them. Placing the error in a label will cause a screen reader to speak each error as the user tabs through the form fields.

Keyboard Focus

One of the biggest failures with forms is not sending keyboard focus to the field with an error or the list of error messages. Assistive Technology users will have no idea there’s something wrong if the screen reader goes blank or their magnifier does not move focus to the error. When nothing happens after pressing the submit button they will assume your form is broken.

Techniques for WCAG 2.0 – Success Criteria 3.3.1 (Error Identification), 3.3.2 (Labels or Instructions), 3.3.3 (Error Suggestion), and 3.3.4 (Error Prevention (Legal, Financial, Data))

• G83: Providing text descriptions to identify required fields that were not completed
• G85: Providing a text description when user input falls outside the required format or values
• SCR18: Providing client-side validation and alert
• SCR32: Providing client-side validation and adding error text via the DOM

HTML5

Now that you’ve got the basics out of the way, adding HTML5 validation and usability enhancements is a piece of cake!

Required Attribute

With the HTML5 required attribute and HTML5 input types you can put the responsibility of accessible form validation on the browser developer.

HTML

<label for="lname">Last Name *</label>
<input type="text" name="lname" id="lname" required>

<input type="checkbox" name="tos" id="tos" required>
<label for="tos">* I agree to terms of service.</label>

Output

Screenshots of Different Input Types with the Required Attribute in Action on Mac OS X Lion

Browser	Text	Checkbox	Radio
Chrome
Firefox

Of course the required attribute does not work on all browsers, Safari and Mobile Safari being the two where I miss support the most. You can read more about HTML5 browser support at The Current State of HTML5 Forms – The required Attribute by Chris Coyier (@chriscoyier) of CSS-Tricks fame. That resource is a bit out of date as support has improved in many browsers.

Input Types

HTML5 input types greatly enhance the usability and accessibility of forms on mobile devices. In iOS, the iPhone, iPad, & iPod Touch platform, most input types will display a keyboard enhanced for that data format. It is very rare to see forms in the wild take advantage of these simple usability enhancements. By default input type=text displays the normal alphabetic keyboard. If you need to type numbers, the @ symbol in an email address, or the .com for a URL extra taps are required.

Comparison of Input Types and Displayed Keyboard on the iPhone

Type	type=text	type=email	type=tel
HTML	<label for="text">Text:</label> <input type="text" name="text" id="text">	<label for="email">Email:</label> <input type="email" name="email" id="email" />	<label for="tel">Tel:</label> <input type="tel" name="tel" id="tel" />
Output	Text:	Email:	Tel:
Screenshot

input type=date on iPad & iPhone

HTML

<label for="date">Date:</label>
<input type="date" name="date" id="date" />

Output

Date:

Because these different keyboards and spinner controls are native to iOS they’re accessible by default. Apple’s done all the work for you.

Pattern Attribute

HTML

<label for="zip">Zip Code 5 Digits</label>
<input type="number" pattern="[0-9]*" maxlength="5" min="0" name="zip" id="zip">

 Output

Zip Code 5 Digits

iPhone Keyboard Comparison Screenshots
with Pattern Attribute

input type=number	input type=number pattern=”[0-9]*”

Using the pattern attribute, pattern=”[0-9]*”, with the number input type will display the 10-digit numeric keypad similar to the tel keypad. This is much more usable than the standard number keyboard which shows a lot of keys that are not needed for simple numeric input like a Zip Code. We have fat fingers and mobile keyboards have tiny buttons. Anything you can do to increase the tap target size of a button really helps out!

HTML5Pattern.com has Regular Expression patterns that can be used to validate complex input types. These are live and can be tested in supported browsers.

You can visit HTML5 inputs and attribute support in a browser to test its support for HTML5 forms and click through all the input types. Another great page to test support for HTML5 form attributes is the jQuery Mobile – Text inputs Docs. I love the jQuery Mobile project as it does two things I’m passionate about, mobile & accessibility, very well!

Input Types Add More Stringent Validation

By adding an input type=email the browser will ask for more specific input formatting to make sure the user actually types an email address in the format name@domain.com.

If we add the required attribute to input type=number Firefox will ask for numeric data that matches the specified pattern attribute.

Simple Mobile & Screen Magnification Usability & Accessibility Enhancements

Place Label Above Input

By placing the label directly above the input you improve the experience for mobile and screen magnification users. When focus is in the input the label will no longer be cut off like in the below example of the Gmail sign up form where the label is placed to the left but cut off when viewed on an iPhone.

Position Formatting Instructions Below Input with CSS

Using CSS you can enclose formatting instructions in a span tag and position them directly under the input so they are still visible when zoomed in.

HTML

<p class="instructions-container">
  <label for="zip">Zip Code <span class="instructions">5 Digits</span></label>
  <input type="number" pattern="[0-9]*" maxlength="5" min="0" name="zip" id="zip">
</p>

CSS

.instructions {
	position:relative;
	top: 1.6em;
	display:block;
}
.instructions-container {
	margin-bottom:2em;
}
.instructions-container label {
	margin-bottom:-1.2em;
}

Output

Hiding Labels Using CSS

You may want to visually hide some labels where the input might be obvious to most sighted users. We can use CSS positioning to do this. The code for this comes from the WebAIM article, CSS in Action: Invisible Content Just for Screen Reader Users.

HTML

<label for="areacode">Phone * <span class="hidden">Area Code</span></label>
<input required type="tel" name="areacode" id="areacode" maxlength="3">
-
<label for="threedigits" class="inline"> <span class="hidden">First Three Phone Digits</span> *</label>
<input required type="tel" name="threedigits" id="threedigits" maxlength="3">
-
<label for="fourdigits" class="inline"> <span class="hidden">Last Four Phone Digits</span> *</label>
<input required type="tel" name="fourdigits" id="fourdigits" maxlength="4">

CSS

.hidden
{position:absolute;
left:-10000px;
top:auto;
width:1px;
height:1px;
overflow:hidden;}

Output

You can disable CSS and the labels will become visible.

Demo Form with HTML5 Validation

Next Steps – Add WAI-ARIA

In the next blog post we’ll build off the work we did here and add ARIA form and validation enhancements that are only visible to screen readers.

Comments? Questions?

So what do you think about HTML5 form validation? Is this a viable option with the limited browser support of the required attribute? Do we still have to rely on JavaScript validation or even server-side validation since a small percent of users disable JavaScript?

Let me know if you have any suggestions for improvement or find any mistakes. Leave a comment below or send me a message on Twitter @pauljadam.

If you’d like to lean more about Deque and the services we offer, please contact us.