If not, they are denial, anger, bargaining, depression and acceptance.

If the names of those phases aren’t a fit for what happens in the accessibility world, I don’t know what is. We all progress in our understanding of accessibility—both at a personal level and at higher level within our organizations (at least, we hope so!)

Have you seen these stages of Accessibility in your organization? How do you know which stage you’re at? Here’s some famous quotes we’ve heard over the years that might help you figure out where you are.

Denial

• “This is a web ‘application‘ so those rules don’t apply to us”
• “We’re not the government so we don’t have to make this accessible”
• “People with disabilities don’t come to my site… they just aren’t my customers”

Anger

• “I can’t believe they’re making us do this!”
• “Why don’t our team members know how to do this already!?!”
• “This is just going to cost us money that we’ll never make back!”
• “This is so unfair!”

Bargaining

• “What about making it just level A compliant instead of AA?”
• “Can we just leave that part for later?”
• “I know we have three web sites, but can’t we just make one of them accessible?”
• “The mobile site doesn’t need to be accessible because our main site is.”

Depression

• “Sigh. We’ve done all this work, and its made no difference, and that consultant still told us we did it wrong…”
• “This is really hard, and there’s so much to think about”
• “What’s the point? No matter what we do it won’t be good enough”

Acceptance

• “Lets make things as accessible as we can, in a way that doesn’t compromise our business goals, or the aesthetic quality of our site. And, if we need to make changes later to make it more accessible, then we’ll do that too.”
• “We can do this!”

Where are you?

So, where are you? It would be great if we were all at the acceptance stage, but that might not be realistic. In which stage is your organization? Have any quotes you’ve heard over the years that you can share from inside your organization or from your clients? If so, please do share (anonymously, if you like!)

onclick="this.value=''"

OR 

onfocus="this.value=''"

What does this code do when it’s used in a form field? Why is it there in the first place?

It is mostly used to clear out “default input” that is already in a form field.

Here is an example: Click or Tab to place the cursor in the field. Then type something into it. Then Tab away from the field to the Go button. Then Shift+Tab back to the field.

What’s wrong with this picture?

Yes, I know. It is just bad code. You can get around this partially by improving the JavaScript. Something like:

onclick="if (this.value==this.defaultValue) this.value=''"

That way the JavaScript only clears the field if the defaultValue is in the field still. You could also use HTML5′s placeholder attribute, with some fallbacks for those browsers that don’t support @placeholder yet.

And, yes, I know that if you’re reading this, you’d never use code that indiscriminately removes whatever input is in the field. But someone out there did and does, because we see it in apps we’re testing all the time.

Why do we build things like this?

I can’t say for certain that this is always the case, but I think part of the reason we see it often is because people consider only two cases when they’re coding, or unit testing or doing Quality Assurance testing on a web site or application. Or it was done in a hurry. Or it was copied and pasted in haste from a bad tutorial site somewhere and nobody caught it when testing. The problem here is that this code indiscriminately clears the data out of the field, even in cases when you don’t want it to. It assumes that if there is *any* data in the field at all, that it should be cleared out.

How this relates to testing

There are two basic cases most people would test for (in acceptance or Quality Assurance testing, for example). The correct case and incorrect case.

The correct case: with a default value in the field, the user would place the focus in the field, the default would disappear and they’d enter some correct data in a field and submit the form.

The incorrect case: with a default value in the field, the user would place the focus in the field, enter some incorrect data in the field and submit the form.

A QA tester would look at the results of the form submission and determine that the system responded appropriately or not. Tests complete. They might even test that the form has a label.

But user experience, and certainly accessibility, need to take into account many different scenarios. Not just a simple “the user entered information correctly” or “the user entered information incorrectly.” To understand the full impact of this code faux pas on user experience, we have to understand a bit more about how people with disabilities use the web, and we need to look not just at the “correct” or “incorrect” case, but the “correction” case where the user enters incorrect information, realizes they’ve made a mistake, or needs to check to see if they made a mistake before they submit the form. Here are a few scenarios:

Typing Difficulties

Javed enters a phone number with the correct number of digits, but mistypes. He needs to correct only the second last digit of the phone number as the rest of the digits are right.

A person that has difficulty typing—whether they’re using their hands, a mouth or head wand or some other device—might take a significant amount of time to enter a phone number into a field. How frustrated do you think Javed might feel when he encounters this type of script? Picture this: it takes Javed 30 seconds to type a phone number—something that you might type in less than 2 seconds. 

And when he tabs or clicks into the field to fix that one digit, that JavaScript takes away all the digits that it took him 30 seconds to type. Now, he needs to start over.

Voice Recognition Software

Susanna’s browser auto-filled her phone number correctly but in the wrong field. It auto-filled her mobile phone number into the work phone field, and her work phone number into the mobile field. She needs to swap the numbers, even though both numbers meet the required pattern for phone numbers.

She tells her voice recognition software to focus on the phone number field for her mobile phone number and intends to tell her software to “select that” and “cut that” so she can move to the work phone number field and paste the phone number in there. And what happens when she uses the software to focus on the field? Her data disappears and she has to enter it again using her auto-fill which is may get it wrong again, or she has to dictate it—more work than she would have had to do with a simple cut and paste.

Using a Screen Reader

Latosha types her phone number into the field, but she doesn’t know if it is correct or incorrect until she double checks with her screen reader.

Think about Latosha. She types her phone number into the field, leaves the field to fill out more of the form, and then comes back to the phone number field to double check and suddenly her data is gone. Latosha can type quickly, but now she’s confused. A form field she thought she had filled in is now blank. What does that mean? Is there another phone number field to be filled in that she missed the first time around? Is this a different form on the same page? Is this even the same page?

Transitional Cases

Let’s be clear: every single one of these issues is a usability issue that would affect all of us. But, they are issues that have a much more significant impact on people with disabilities than they would on people without.

These are all “transitional cases” that need to be tested and accounted for in an application’s design. You can’t simply design or test for the correct case (“the user entered information in the right format”) and the incorrect (“the user entered incorrect data”) case and be done with it. You must test for the transition from the incorrect state to the correct state.

We’ve only described three cases where we don’t want to automatically clear out data that is in the field. There are countless others.

But you don’t need to count them. You just need to know that you almost never, ever want to use this line of code in your app:

onfocus="this.value=''"

And if you test for the ability to check your work, or make corrections with Javed, Susanna and Latosha in mind you’ll catch it.

Next Actions

• Examine your apps for code that removes data from fields. If you find it, it’s time to have that difficult conversation with your manager, or colleagues. You need to revisit this with them.
• The next time you’re wireframing, designing, creating user stories or test cases, use these descriptions above to make sure that you’re not creating something that is less usable than it should be.
• Make sure that when you’re testing your applications you’re not just testing to see if the application recognizes correct and incorrect input. Test to see how easy or difficult it is to move from the incorrect state to the correct state.

We talked about several topics in the interview, but there is one that I simply must discuss a little further: Audio transcription. It was the topic of about the first 15 minutes or so of the interview. You can hear the podcast on the Boagworld site: Boagworld Podcast Season 2, episode 6.

We’ve also provided a well-formatted and cleaned up version of the transcript of the podcast that tracks speaker names so that you can follow the conversation a bit better.

Let me highlight a few key components of my discussion with Paul regarding audio transcription.

Format

We often think of a text transcript of an audio file as an alternative format. Please remember that for someone that can’t hear, the text transcript is the primary format. We simply can’t forget that. People rely on the transcripts of our audio content as it’s the only way they can consume it.

Who decides?

In the interview Paul says that he normally posts an accompanying blog post that doesn’t include all the back and forth between he and Marcus, the other host of the podcast, and that the blog post is actually “better” than a transcript. In the interview, I suggested to Paul that the back and forth banter helps show what the relationship between Paul and Marcus is like. Someone that can’t hear, might be interested in that too. They also might not be. (You could actually argue that maybe nobody is interested in that and it should be edited out of the audio version, too, but the Boagworld audience has been split roughly 50-50 on whether or not the banter should be part of the podcast).

The question is, who gets to decide what’s important to the person that is reading instead of listening? That should be the user that decides. If you publish it for someone in audio format, publish the same thing in text format.

Scheduling

Paul suggests that if you record audio and wait to get it transcribed before you publish then it causes scheduling delays. There’s only a delay if you’re always running to catch up and things aren’t scheduled ahead of time. If you have a calendar, you can schedule release dates where the audio and transcript are released together. Schedule it ahead of time; it’s your job.

Finally, Pragmatism

Paul and Marcus mention a few times that you have to be pragmatic about accessibility. “How far do you go?” they ask. Paul says at one point in his discussion that “Derek was pushing me to do better than I was already doing.” Yes, yes I was. I’ll keep doing it, too, to anyone that I meet that is in this industry. To anyone that attends my conference talks and accessibility workshops.

How far do you go? “Pretty far” would be my response. We have to aim for the stars and set a very high standard.

While people may argue that pragmatism is about deciding what is “good enough” what they usually mean is that what they’ve done is “better than nothing.” There is a place for compromise. We do it all the time in our work. But it’s usually a compromise that means “less than optimal access” to the information that’s there, not “no access” at all.

Pragmatism includes planning. It includes budget. And it includes people with disabilities… as many as we can.

I started teaching people about ARIA in 2006 at Web Directions South in Sydney Australia. I was delivering a full day workshop on building accessible web apps, and showed an example that essentially boiled down to this:

<span x2:role="role:checkbox" aaa:checked="true">
	Include decorative fruit basket
</span>

That’s a simplified version of a W3C example that used namespacing (that’s what the x2: and the aaa: are before the role and checked attributes). The syntax for ARIA has changed since then so that we no longer require namespacing. Today we’d end up with something a bit simpler like:

<span role=”checkbox” aria-checked="true">
       Include decorative fruit basket
</span>

I still use this example in my workshops today because it illustrates a number of great points—like, if you’re using role=”checkbox” instead of a native checkbox, you’d better have a really good reason.

From the very first time I used that example, I had people saying to me: “but that won’t validate.”

What about validation?

They were right, you know. We should all be writing valid code. I suggested to them that they could break the rules for validation anyway.

“We require our code to be valid” they said.

Fantastic! This is exactly where we should be aiming.

I’m not exaggerating when I tell you that I had this very conversation with someone just last month in a full-day training session. I told them flat out, break the rules.

We’re not talking about throwing out all the rules here. I’m specifically talking about ARIA. ARIA adds programmatic accessibility where it just didn’t exist before. It allows us to programmatically specify what an interface component is beyond the collection of markup and CSS that it is comprised of. We can say “This is a slider” or “this is a tree” or this is a set of tabs (even though each them might be just a collection of <div> and <span> elements). If you want more of a primer on ARIA, I wrote a brief primer in my article on A List Apart: ARIA and Progressive Enhancement.

Now then, you can add ARIA to HTML5 and you can even validate with some of the newer validation services. validator.nu and even the w3c’s validator have support for validation for HTML5 + ARIA (just remember, HTML5 and ARIA still aren’t completely specified and implemented yet, so there are quite likely some issues that may crop up when you’re validating).

But what if you’re not using HTML5 and your web app is HTML 4.01? or XHTML 1.0? Then what?

You can switch your DOCTYPE to HTML5 so that your app/documents are recognized as such, and would therefore allow ARIA’s role and other attributes to be valid.

Or—and this is where I get a bit crazy—you can just leave your DOCTYPE alone. Leave it as HTML 4.01. Leave it as XHTML 1.0. Add ARIA anyway. Break the rules.

Adding ARIA adds accessibility

Because the potential good that you’re creating by adding in accessibility like this outweighs the problems that are created by not having valid code because you added ARIA. What problems are created by adding ARIA’s role and other attributes to HTML 4.01 or XHTML 1.0 documents? Precisely none. Why not?

If a browser doesn’t understand an element or an attribute, it just ignores it.

The browsers ignore role and other ARIA attributes. Assistive technology such as screen readers that run on top of those browsers, use the ARIA attributes for good, not evil. It doesn’t matter if they’re using it with HTML5, HTML 4.01 or XHTML 1.0.

Use ARIA with whatever version of (X)HTML you’re using. Even if it doesn’t validate.

If breaking a rule like validation by adding ARIA means that your interface becomes more accessible then do it.

Yep, I’m a rebel.

Here’s an example from the page showing our upcoming tour of workshops to Australia:

<a href="http://feathermelbourne.eventbrite.com/">
<h3 class="summary">Melbourne</h3>
	<span><em>Supported by WIPA</em></span>
	<span>July 25, 2011</span>
	<span class="button">Purchase Tickets</span>

	<img src="star.png" title="Melbourne" alt="" />
</a>

The block link makes the entire block of content clickable without using multiple links. We just couldn’t do that in (X)HTML. Traditionally we would have made the heading clickable with a link inside the <h3> and then another link around the rest of the content to make it clickable, and then we might add JavaScript to deal with the clicks that happen in the spaces around and between the links and some CSS to create :hover to create the invitation to click anywhere on the block.

Block links are the perfect solution for this because:

• they don’t rely on or require any JavaScript
• they create fewer “tab stops” on the page, making it easier for keyboard users to navigate
• they automatically create a large, block clickable area, making it easier for everyone to click

It is completely invalid (X)HTML though, isn’t it?

And because of the ways these types of validation/nesting errors are corrected in browsers, assistive technologies react to these in different ways.

Testing, Testing, 1, 2, 3.

Lets take a look at what actually happens when we put block links to the test with a couple of pieces of assistive technology.

With a screen reader, the behaviour depends on the mode you’re using to interact with the links (via tabbing through the interface, listening to a summary of the page, reading a links list, or listening to the entire page with “say all” mode).

With the Jaws screen reader, when navigating using the tab key, the only part of the block link that gets read is the first content in the link. In this case, the heading “Melbourne” or the other city names. When navigating using the arrow keys, though, the heading is identified as a link, as is the rest of the content that is contained in the block link, effectively creating two links. When using the links list dialog in Jaws, the block link is identified as one link.

With Voiceover on the Mac, the link text is repeated when it is read out when navigating using the tab key but is only seen as one link:

To summarize, sometimes the link will be recognized as one link and other times as two, sometimes the content is repeated and sometimes portions of the content are not read out at all.

The behaviour depends on the combination of screen reader, browser and navigation mode.

We don’t want it announced twice, though that is definitely better than the link contents not being announced at all.

We tested the same block links with Dragon Naturally Speaking (voice recognition software) and were pleased to find that it recognized each block link as just one link.

So, what are we to do?

We decided to forge ahead with block links. Yes, the content gets read out twice in certain situations, but it is better to be read out twice than not at all.

In fact that was one of our biggest concerns: portions of the link not being read out. However, in this case, we’ve front loaded the most important part of the link (the name of the city) so it’ll be the first thing read out. And even though the date is not read out in certain scenarios, it is one of the very first pieces of content on the Event Brite registration pages. So, while it isn’t perfect, it is a compromise we’re willing to make. We may also look at changing the markup so that it is read out as part of that first block.

And remember: these issues will eventually go away as browsers and assistive technologies fully implement HTML5 compatibility. This isn’t even an issue that is “HTML5′s fault” so to speak. It’s just based on the way browsers recover from markup that they consider to be invalid.

For now, we’ll keep experimenting with block links and other HTML5 constructs in different scenarios and examine each situation on a case by case basis. This is only the tip of the iceberg when it comes to HTML5 and accessibility so we’ve got to keep moving forward with these solutions and dig deep into the accessibility implications and make smart decisions about what we implement and how we do it in the best possible way.

• Blind people that use a keyboard because they can’t use a mouse

• People with low-vision that use a keyboard some of the time
• People with mobility or dexterity impairments that simply prevent them from using a mouse.

Generally, we’re talking about both sighted and non-sighted keyboard users.

It is now, and always has been, a fundamental for accessibility, period. It is one of the first things we check for when testing a site or application for accessibility and usability issues (Yes, I did say usability issues — proper keyboard accessibility makes it easier for everyone to use, disability or not.)

Problems with content

When working with straight up HTML based content, your keyboard accessibility issues are non-existent. With HTML, things like form fields, buttons and links just work, because keyboard accessibility is built in to the browser.

But start mixing content and you get… well, mixed results. Here we look at one example — YouTube videos embedded in a page.

As soon as you have mixed content embedded in a page, we encounter issues with what I refer to as “keyboard scope.”

As an example, open up FireFox and try to tab to the video controls on the page for our screencast Images in Context.

In order to control the movie with the keyboard, you need to click on the Flash movie to give it the focus first. Read that again. You need to use the mouse to click on the movie first in order to use the keyboard.

How we “solve” the problem

When we embed YouTube videos in our pages, we always include an external set of controls that control the key functions: play/pause and mute/unmute. These are added to the page with JavaScript (they only function with JavaScript on, so there is little point in having them on the page when JavaScript is off or unavailable) and utilize the YouTube API to control the movie.

We add two simple, natively accessible <button> elements to the page. Here’s the Play/Pause button:

$.fn.youtube_controller = function() {
    var player = $(this);

    var playButton = $('<button />', {
        text: 'Pause',
        id: 'playBtn',
        click: function(e){
            e.preventDefault();
            var ytplayer = document.getElementById('video-player');
            if (ytplayer) {
                playerState = ytplayer.getPlayerState();
                if (playerState == 2 || playerState == -1) {
                    ytplayer.playVideo();
                    $(this).text = 'Pause';
                } else if (ytplayer.getPlayerState() == 1) {
                    ytplayer.pauseVideo();
                    $(this).text('Play');
                }
            }
        }
    });
    $(player).append(playButton);

Then we style them to make them appear just like the regular Flash YouTube controls. They’re positioned over top of the embedded YouTube movie so that the buttons are in exactly the same place as YouTube’s controls. We style them to look the same, including the :focus states, and then position them over the movie:

#watch-player button {
-webkit-border-radius: 0;
-moz-border-radius: 0;
border-radius: 0;
background: transparent;
position: absolute;
bottom: 6px;
text-indent: -9999em;
margin: 0;
padding: 0;
width: 30px;
height: 26px;
}

.main #watch-player button:focus {
    border: 3px solid yellow;
    outline: none;
}

#playBtn { left: 0; }

#muteBtn { left: 30px; }

Now, go use the keyboard to tab to the “Play/Pause” button on the embedded version of Images in Context

See how it works? The controls are actually living outside the movie and that provides easy keyboard access to everyone.

Not Perfect

Now, this solution isn’t 100% perfect. Sometimes I think we should actually leave the buttons outside the movie and NOT style them to be positioned over top of the YouTube movie so that the buttons are more obviously available to everyone.

I also feel that we need to include some of the other controls that are in the movie — a volume slider, a timeline scrubber, and a fullscreen control.

We could conditionally execute the JavaScript so that it doesn’t create duplicate controls where the tab focus issues have been resolved (IE9 and FireFox 4 both seem to have solved the tab focus problem; unfortunately we know how long it takes to get browsers upgraded in some environments.) Having a duplicate set of controls is certainly the lesser of two evils though — much better than not being able to control the movie with the keyboard at all.

• View the transcript for this video
• View this video on YouTube

If you use display:none, then screen readers don’t get that content. It is better for accessibility to use off-left positioning instead of display:none

The next thing you know, someone has it in their head that this is a binary situation: display:none is bad for accessibility and off-left positioning is good for accessibility.

Here’s the thing, though–sometimes you WANT to use display:none. Sometimes you want to use off-left positioning.

I actually saw an example recently that used off-left positioning and they said right in the comments:

/* keep this off-screen because it is more accessible than display:none */

Off-left positioning is a technique that is often used in image-replacement that allows you to essentially create a text alternative for CSS background images that are used in your designs. It has also been used for other things like hiding menus and other content off the screen–often in the name of accessibility.

The case I saw the other day was using off-left positioning for creating a CSS only hierarchical menu.

Here’s an example of how it was done:

http://simplyaccessible.com/examples/css-menu/

There are 4 menu items that have sub-items that show when you use the mouse to hover over the items.

Now, start to tab through that page with your keyboard. What happens when you tab from the “About” link? Let me highlight this for you:

The keyboard focus is placed on the next link (“The Company”) that is still hidden from view because it is hidden using off-left positioning.

The keyboard focus is now invisible to someone that is a sighted keyboard user (remember, screen reader users aren’t the only people that use a keyboard for navigation!). The focus disappears until “Services” gets the focus and then disappears again and again after each main navigational item as the off-left sub-menus have the focus.

Fixing the problem

There are several ways to solve the problem, each of which take into account two key considerations:

1. Keyboard access to all content for everyone.
2. Elements that aren’t visible on the screen shouldn’t (generally) be able to receive the focus.

Here are a few options that we’ve cooked up for you to look at. And please, while you’re looking at these examples, go through them with a keyboard (both forwards and backwards) to see the kind of keyboard access they provide compared to the original.

Option 1: use display:none instead of off-left positioning and set the menu such that :focus doesn’t turn it to be display:block. This would require the “landing pages” for each of the top level menu items to have the equivalent sub menu items readily available on the page. http://simplyaccessible.com/examples/css-menu/option-1

Option 2: use display:none and have a :focus state to match :hover that makes it display:block and brings the sub menu items onto the page, allowing them to receive the focus, but only while they are on the screen. http://simplyaccessible.com/examples/css-menu/option-2

Option 3: use off-left positioning but use :focus to bring it back on the screen. Again, this would bring the sub menu items onto the page and allow them to receive focus, but only while they are on the screen. http://simplyaccessible.com/examples/css-menu/option-3

Note: We aren’t going to include an ARIA example here. That’s for another article

The Real Problem

The problem isn’t so much that off-left positioning was used. The problem is that it wasn’t used appropriately combined with the faulty assumption that we need to use off-left positioning because it is more accessible than display:none. Someone came to understand through their own experimentation or hearing or reading that display:none isn’t good for accessibility and THEN implemented a solution without thoroughly testing for full keyboard access.

If you’re developing anything for the web make sure that you have efficient keyboard access to everything, and that you’re not allowing the focus to go off the screen to elements that are hidden off-left.

Now that would be better for accessibility.

Even the simplest of things aren’t as straightforward as we’d like them to be.

Take a look at noting required fields for a form. You’ve likely seen hundreds of ways to tell a person that certain fields are required over the years. Just yesterday, I saw this example:

Here’s the code that is used to show that this is a required field:

<div class="requiredField"></div>

div.requiredField {
	background-color: #DC2222;
	width: 3px;
}

There is nothing in the HTML — no information at all — that indicates required fields. It is all being done entirely with an empty, semantically meaningless div and some CSS properties. This means that it is a completely visual solution, and has nothing available for a screen reader or other assistive technology to read.

So what are you to do?

Simple.

Content (HTML) is your most reliable way of showing people what fields are required.

• It can be the word “required” in your form label.
• It could be an asterisk, or even an image of an asterisk.
• It could simply be a statement that “all fields are required” before the form.

In the future, that may change to include other techniques like adding HTML5′s “required” attribute or even ARIA’s “aria-required” attribute.

For now, it needs to be in your content, not your CSS.

The Future

We study form interaction a lot — it is usually tops on the list for our clients when we’re looking at their web apps. If you’re interested in a deep look at more modern methods, go read our article over at A List Apart:

ARIA and Progressive Enhancement

The meatiest part of the article is a detailed look at modern techniques for denoting required fields.

Take a look at the Going a bit deeper section. It may overwhelm you, but you’ll see the details of testing several different scenarios for noting required fields. We test methods for showing required fields like HTML5′s required attribute and ARIA’s “aria-required” attribute. At the end of the day, we always come back to our standard method of including appropriate content in the form label. We started using that method in 2005 and have been using it ever since.

If you need to make your forms accessible, please take a look at our Virtual Seminar In Top Form: Designing and Building Accessible Forms. As a bonus, we’re giving everyone that registers a copy of Luke Wroblewski’s Web Form Design book (a $22 value). Sign up now

I managed to take advantage of the beautiful weather, blowing and vacuuming up the leaves and mulching them into a fine dust, and loading them all up into recyclable bags. 12 bags in all, 6 hours of work.

The next morning my right wrist was swollen up to be about the size of the roundness of a small apple. I’m having a really tough time flexing my hand, I can’t bend my wrist and holding onto anything is proving to be quite a challenge. When I do flex my hand I can hear a creaking noise that sounds like rubber tubing rubbing up against a ball of cellophane.

I can’t use my hand right now and it is slowing me down. I composed this entire blog post using Dragon dictate for the Mac. It’s quite accurate and I didn’t need to complete much training. Hopefully this won’t last long but I’m very thankful that I have been exposed to voice recognition software over the years in our accessibility work, so I know how to use it reasonably well. Even with that, the dictation part was the easiest. Actually posting proved to be a bit more challenging and is likely to become a series of posts on using Dragon Dictate on the Mac.

At some point in your life you may break down. You may get injured. Your abilities to do the things that you do now may decrease. Vision, hearing, dexterity, mobility, cognitive abilities — any or all of them may change in your future.

Right now you might be focusing on building accessible websites for other people. Someday you may be hoping that others are building them properly for you.

This fits very well with the way that I’ve always tried to approach accessibility:

I don’t care what technology you use, as long as you use the accessibility features of that technology properly.

I know it isn’t quite that simple, and I generally advocate using HTML-based solutions over others, but in reality, at the end of the day, if you can support accessibility with what you build with Technology X, then do it.

I was very very happy to see that the W3C recently published an update to the Techniques for meeting WCAG 2.0 that included a huge number of Flash specific techniques for WCAG 2.0. Even if I don’t always agree with the choice to use Flash, that isn’t my battle. My battle is making sure that if and when you do choose Flash, you implement accessibility. People are going to continue to use Flash and they need to have the tools and techniques to ensure they are creating accessible content.

What about non-web content?

I’ve seen and heard this a few times in the last while — someone will post a message to a mailing list asking “We’re building an application for iPad/iPhone. Is anyone else doing that with a focus on accessibility and if so, are you following WCAG 2.0?”

People inevitably point to Apple’s Accessibility Programming Guide for iOS to provide guidance for making accessible iPhone apps. That is excellent advice — it is comprehensive and has a lot of valuable information.

Other responses flatly dismiss WCAG 2.0 for this scenario — “WCAG 2.0 is meant for web content only.”

My take? Just because something isn’t web content, per se, doesn’t mean that we can’t still take the core principles of WCAG 2.0 and apply it to an iPhone app. WCAG 2.0 is based on user needs. Your content and functionality, whether part of an app or delivered via browser, needs to be:

• Perceivable.
• Operable.
• Understandable.
• Robust.

Nothing precludes you from using WCAG 2.0 as a framework for assessing an iPhone app. Your app’s functionality and content needs to be perceivable, operable, understandable and robust, doesn’t it?

The implementation details are different than with HTML. Even so, we’ve used WCAG 2.0 as a framework for assessing iPhone apps, Flex/Flash applications, and even Java and other desktop apps as part of our accessibility consulting.

Even if it isn’t “web content” per se, core user needs remain.

Have you used WCAG 2.0 as a framework for other types of content? I know all the guidelines don’t necessarily apply in a non-web context, but what other challenges did you run in to? If so, we’d love to hear about it… please do share!

I love user styles because they allow us, the users, to customize the way we want things to look. We can modify and override what the author suggests in their style sheets so that our preferences take priority over the author’s. My browser, my fonts, size, colours and layout.

Most browsers, including Internet Explorer, FireFox, Chrome, Opera, and Safari (see Safari 5 User Styles) all have mechanisms built into the browser that allow us to apply a user style sheet. This may be done at the browser level or through an extension mechanism, but ultimately this lets the end user control how a web page looks. This could be something simple like choosing a different background colour and text colour to be applied to every web site they view to something more complex where styles are reset and then set for every element possible in a web page.

The beauty of this mechanism is that it allows for much more customization of:

• font size
• background and foreground colour combinations
• displaying of hidden content
• arrangement of elements on the page
• size and colour of form controls

The user style sheet gives you full control over how pages appear in your browser.

Unfortunately, we don’t have that ability on the iPhone or the iPad.

Actually, we do, but it isn’t as convenient as setting up a user style sheet.

Here’s an example:

1. I borrowed my friend Wayne Dick’s user stylesheet and uploaded it to: http://examples.furtherahead.com/userstyles/waynedick.css
2. I edited Gez Lemon’s Accessible Style Sheet Bookmarklet so that it includes that URL: Wayne’s Styles (feel free to click it now if you like and you’ll see it in action)
3. bookmark it in Safari, and sync to iPhone or iPad.

Launch that bookmarklet in mobile Safari and you should see something like this:

Limitations

Of course, there are limitations. Here’s what I see as the two most significant:

Persistence. You need to apply this bookmarklet every time a page loads. That’s a limitation you could live with though if you need to be able to read the content with your preferred fonts, colours, sizes, and layout.

Technical savviness. In order to employ this technique, you need to be able to author a user style sheet, upload to a server, edit the bookmarklet, save and sync the bookmarklet. Many end users that need this functionality may not have the chops to do this.

Here’s a helpful thought though – if you are reading this article, the odds are that you DO have the chops. If you know someone that could use some support with things like this, help them out. We’re all in this together, and all that.

To add your own user style go to Preferences > Advanced > Style Sheet and select a CSS file (locally stored or on the network) to use that style sheet.

If you’re unfamiliar with user styles, here is the scoop:

• You have specific text and background colour combinations that work best for you.
• You have a particular font and font-size that work best for you.
• You choose not to display images by default.
• You decide that you want all your form fields to be twice as big as they are normally.
• You want a certain outline around each paragraph so that you can more easily digest a page chunk by chunk.

Whatever the reason, you create a set of styles that make things look the way you want them to. Through the browser itself, or through a browser extension, you tell the browser to use your new stylesheet, and it overrides what the author suggested.

Make sense? This use of technology is exactly why we use progressive enhancement and why we must always remember that other people may not see a web page the same way we do.

Right around that time I was in Phoenix for the 2010 IA Summit, and on Wednesday in my Real World Accessibility for Ajax and Web Apps workshop, an attendee asked about the issues of speed. At his company they’ve been focussed on speed of service delivery for their web site. To the point where they’ve changed the markup to be leaner. For a navigation menu, instead of using an ordered list, they were using simple links without any other markup.

<ul>
	<li><a href="page1.html">Page 1</a></li>
	<li><a href="page2.html">Page 2</a></li>
	<li><a href="page3.html">Page 3</a></li>
	<li><a href="page4.html">Page 4</a></li>
</ul>

178 bytes

versus

<a href="page1.html">Page 1</a> <a href="page2.html">Page 2</a> <a href="page3.html">Page 3</a> <a href="page4.html">Page 4</a>

129 bytes

For that component alone, that’s roughly a 30% reduction in code. It is faster.

Add in style rules to make the list items display:inline, and include any DOM manipulation or traversal and these differences can add up.

I think most people would agree that the first example with the unordered list is more accessible, and provides more semantic markup. We’ve been coding navigation menus as lists of links for years and you likely have been too, for good reasons:

• a list of links provides more context (we’re on item 2 of 4)
• coding it as a list allows a typical screen reader user to jump from one nav block to the next
• we often use nested lists to denote hierarchy in our navigation (though this example doesn’t)

So, where does this leave us, then?

It seems that at a micro level, speed and basic accessibility (and semantics) are at odds with one another.

I sincerely hope the weight given to site speed isn’t something that overpowers other factors like accessibility. Why? Because site speed is about to be the new big thing that companies focus on in order to try to get to the top of the search results. Thankfully they state: “While site speed is a new signal, it doesn’t carry as much weight as the relevance of a page”

Relevance will always be the most important factor (or at least, it better be). Accessibility and speed are important too, so to me, the best way to approach it will be:

1. write/create hightly relevant content
2. use semantic markup and ensure your site is as accessible as it can be
3. use every means to speed up and optimize after you’ve done everything else.

It doesn’t have to be speed versus accessibility, does it?

In this case, the error message is emphasized within the label for the form field. Semantically this makes sense – we highlight error messages with colour, different text weight or other visual means in order to emphasize them anyway. Using a <label>... <em></em></label> not only provides us the elements for styling but also makes sense – the label (and therefore the error message) is specifically associated with the form field using the for attribute.

This technique is essentially an extension of the one used for denoting required fields. The exception is the HTML:

<div>
<label for="uname">Username
<em>must not contain spaces</em>
</label>
<input id="uname" type="text" name="uname" value="" />
</div>

Placing the error message to the right of the field for easy scanning is useful, and the fact that it is still part of the label, and found before the text box in source order allows it to be read out by screen readers. This is a case where a zoom layout could also be used to provide a version to low vision users.

View the Error Messages Example

With the asterisk rendered after the field itself, it is not always read aloud by a screen reader, nor seen by a person with low vision using a magnifier. While it is also the user’s responsibility to understand what fields are and aren’t required, we, as developers and designers, certainly can make it easier for people to discover which fields are required.

A typical strategy is to change the form layout so that the label and its asterisk are listed above the form control itself, making it easier for screen reader users and low vision users to determine which ones are required. As a fully sighted user, I find this type of layout a bit more difficult to use, as I can’t scan quickly to determine the required fields – for me, the layout with the asterisk to the right of the form field is much more usable. So, how do we balance the needs of multiple groups?

Here are two possible strategies that are useful:

1. Very simply, place all required fields in a “Required” fieldset and other information in an “Optional” fieldset. This has the benefit of semantically grouping the fields together, and that the legend is (generally speaking) read out before each of the fields depending on the verbosity settings of the screen reading software. View fieldset example.
2. You could also use semantic XHTML to provide some emphasis to the asterisk and use CSS to place the asterisk part of the label visually after the input control. This relies on absolute positioning within a relatively positioned parent as shown in this illustration:

   

   Here is the relevant HTML for this example:

   <div>
      <label for="uname">Username<em>*</em></label>
      <input id="uname" type="text" name="uname" value="" />
   </div>
   

   The CSS for this technique is fairly straightforward: first, the containing <div></div> is positioned relatively and given an appropriate width:

   form fieldset div {
     position: relative;
     width: 60em;
   }
   

   Next, the label and input are styled:

   label {
     width: 15em;
   }
   input {
     width: 15em;
   }
   

   Finally, we use CSS to place the <em>*</em> to the right of the input:

   label em {
     position: absolute;
     left: 35em;
   }
   

   This provides a benefit to sighted users, and those using screen readers. It doesn’t help low vision users in particular, but a zoom layout would be appropriate for use in this case.

   View label example

The HTML for this example might be:

<div>
<label for="searchtxt">
Search Terms:
</label>
<input id="searchtxt".../>
<input type="submit" value="Search" />
</div>
<div class="group">
<div>radio buttons</div>
</div>

This is a fairly natural way to code the form when using a CSS based form layout – visually the first “row” of the form includes a label, a text box and a search button, and the second “row” includes the optional radio buttons that help refine the search.

View the Search Form Example

Based on what we know about source order, this presents a minor obstacle to a screen reader user as they will encounter the text field, then the search button, and then the radio buttons. They may not realize that the radio buttons exist – the natural tendency is to submit the form once the submit button is reached.

This form layout also causes a minor inconvenience to a keyboard user – to choose the optional radio buttons they must tab past the submit button, and then navigate backwards (often using Shift + Tab) to submit the form.

This problem can be solved by improving the source order and using CSS to absolutely position the Search button as follows:

First, we modify the HTML source:

<div>
<label for="searchtxt">
Search Terms:
</label>
<input id="searchtxt".../>

<div class="group">
<div>radio buttons</div>
</div>

<input id="submitbtn" value="Search" />
</div>

Then we apply the following CSS to visually place the Search button at the top right of the form, much as in the previous examples:

input#submitbtn {
position: absolute;
left: 31em;
}

The result is that we have a form that visually shows the Search button beside the text box, but has a better source order for keyboard and screen reader users. It may also be useful to not position the Search button at all for a Zoom layout, allowing the Search button to fall vertically at the end of the form (while I have implemented the zoom layout in the example, note that it has not been tested with low vision users)

View the Search Form with source ordering Example

• the user doesn’t have to go “back” to search again or refine their search
• the programmer gets to keep their code modularized and reuse the same bit of code over again by maintaining one page instead of two.

However, this does cause some problems for visually impaired users, and (I’ll freely admit) sometimes throws me off for a number of reasons:

• the search form is presented first and, depending on its complexity, pushes the search results below the fold
• there is often no indication that anything has changed – a screen reader user or screen magnifier user are presented with what looks like the same page. On several occasions I’ve been asked in user testing “didn’t I just fill that form out?”
• a keyboard user is required to go through the entire page and search form before getting to the results.

View a typical search and results page that demonstrate these problems.

Fortunately there are a number of things that can be done to improve this functionality.

First, we can change the action of the form to include a fragment identifier/named anchor for the results page.

<form method="post"action="whatever-page.php#results">
... form elements here …
</form>

Next, we create that element within the results page, and use that element to do two things: 1) provide a statement about how many results were found, and 2) link that statement to another node within the page.

Found 25 results for keyword

This accomplishes two things:

1. including the statement itself lets any user know right away that something has changed on the page
2. posting directly to that node places the focus where it is most relevant
3. linking the statement is very clear, and acts as a very precise link that “skips over the form” without actually being called a skip link.

In my final example, I’ve also included a link after the search results that submits back to the form itself to make it easier to “Search again.”

View the improved search and results page

Other considerations

You might also consider it useful to change the page’s <title>...</title> to indicate that you are viewing the results page as well as the number of results found, or which ones you are displaying.

It may be useful when this is implemented within a template to actually submit to a named anchor or ID that is just above the desired target so that the target isn’t right at the very top of the viewport.

Providing some other visual cue to draw attention that particular node/link would likely provide benefit as well.

This technique could be applied to any form on a page that submits to itself.