The one benefit which it will provide is a little extra time to debug the new OAuth version of WP to Twitter before it becomes the only working version.

There are a lot of complications surrounding the OAuth update — most of them unfortunate. For the first time since I began work on this plugin, I had to remove features. As far as I can tell, there’s no way to operate two separate user accounts with an OAuth authenticated application, for example. As a result, I’ve had to remove the ability to assign separate author accounts for Twitter posting. As development progresses, a way forward may show up — but for now, I just don’t really have another option.

My biggest request at this time: if you can, please decide you’re willing to use this version now, to provide me with feedback so it will work as well as it possibly can when all past versions cease to be functional.

There will be problems; I’m sure of it. I just hope to find them all soon enough.

WP to Twitter Updated to OAuth
Copyright 2004 – 2010 Joseph C Dolson, Accessible Web Design

To help explain these changes in Federal web accessibility standards, I’m going to look at three specific questions. These questions will hopefully answer some of the questions concerning what’s coming up:

1. Has this changed anything about who must follow Section 508 guidelines?
2. What has been the primary reference for changes to Section 508 rules?
3. What are the specific changes to the Section 508 documents?

Has this changed anything about who must follow Section 508 guidelines?

No. The section 508 rules still exist under the same body of law — this is not a revision of the application of the law, it’s only a revision of the methods which are acceptable in following the law. Section 508 continues to apply only to Federal departments or agencies or entities providing services or products to Federal agencies. Further, it only applies to the specific services or products provided by those contracted entities, not to any external presence or non-Federally funded projects.

What has been the primary reference for changes to Section 508 rules?

Based on the document guidelines and on references made in the updated document, it seems that the primary reference was the Web Content Accessibility Guidelines, Version 2.0, as created by the World Wide Web Consortium. In fact, there is a specific section referring to WCAG harmonization, which indicates that web pages as defined under WCAG 2.0 which are conformant to Level AA will be considered to be in conformance with Section 508 (with a few elaborations on additional requirements.)

This is an excellent change, since it explicitly states a subset of requirements which need to be reviewed in addition to WCAG 2.0, Level AA requirements. From a consulting perspective, this simplifies the process: you can review WCAG 2.0 requirements, then check the additional requirements under Section 508.

The additional requirements are fairly straightforward. A significant percentage of them relate explicitly to video accessibility — an area which WCAG 2.0 frequently describes as Level AAA requirements. It seems clear that the Section 508 review group was concerned about the use of video in government communications, and wanted to be sure to avoid a situation where creating a video would allow Federal agencies to ignore Section 508 requirements — which is certainly a wise concern.

What are the specific changes to the Section 508 documents?

To work through all of the specific changes would be a Herculean labor — and I’m not prepared to undertake it right this moment. I’m not sure an article is the right place to do this, in fact. A permanent document demonstrating the changes may be more valuable, in the long run. Suffice it to say that the basic fundamentals of Section 508 have been updated to reflect the changes between versions 1.0 and 2.0 of the Web Content Accessibility Guidelines. The requirements which are beyond the specific conformance expectations of WCAG 2.0, Level AA are worth elaborating on, however!

Chapter 4, section 409: User Preferences. This section explicitly requires that applications allow users to set preferences for color, contrast, font type, size, and focus cursor. Thankfully, the rule is clearly written when it comes to development which is operated within a web browser: web browsers, as platforms which take some settings from an underlying platform, are expected to allow the underlying platform’s settings for these issues to take precedence.

To clarify this in simple terms: web browsers, or applications running within web browsers should not over-ride settings from the operating system.

Chapter 4, section 413: Authoring Tools. Essentially, this is an extension of the web authoring tool accessibility guidelines applied within Section 508. What it requires is that any tool which is used to author content or create documents — such as Microsoft Word, as a desktop application, or as WordPress, as a web-based content authoring tool — must allow the creation of accessible documents (such as by allowing the creation of alt attributes for images) and must not by default remove any accessibility feature — such as a video editing tool which would remove captions if editing a captioned video.

The section seems very reasonably written — it requires prompts for creating conforming documents, but also specifies that not every element should be prompted, as this can decrease usability.

Chapter 6, section 604, part 4: Real-Time Video. Live, streaming video must include real-time video description, with certain exceptions. This seems pretty explicit, and definitely is a valuable addition for people with disabilities. The exception provides for an exclusion for primarily visual and unattended situations. The example provided is a web camera overlooking a national park — it is purely visual, and there is little to no significant information to be gained from live video description.

Chapter 6, section 604, part 5: Multiple Visual Areas of Focus. When a video contains multiple areas of focus — such as a news program which also includes scrolling event notices beneath the main program — video description must be provided for all areas of focus. The provision suggests a couple of methods for accomplishing this, including divided audio tracks between left and right channels. It’s an interesting area to address. I can certainly see that this requirement can open up new areas of information availability to people with disabilities, but I can also see a number of potential problems in implementation. However, that is a question for another time!

Chapter 6, section 607: User Controls for Captions and Video Description. User controls must meet certain standards for accessibility functionality: in addition to the requirement that controls for closed captions or video description need to be present, they must also be present in the same context as other controls. It is not an acceptable option to hide controls for closed captions or video description in a corner — they should appear in contexts which have a similar prominence to other controls such as channel selection or volume adjustment.

Chapter 6, section 608: Audio Track and Volume Control. Essentially, media players must provide users an ability to isolate speech tracks and background sounds. This is obviously dependent on video production in order to function; as such, this section indicates that any videos produced must be produced with separate speech and background audio tracks, in addition to requiring that players must offer controls to separately adjust these tracks.

This clause seems to have some flaws to me — specifically, in the gross generality of “background audio” versus “speech.” Stating “speech” is very explicit, as it only refers to spoken text. However, in practical terms, there are actually three important bands of audio in synchonized media: background audio which is non-referential (music and some background sound effects), audio which is referential (some background sound effects: a knock at the door or other sound which is reacted to by the video), and speech. It can create a great deal of confusion to exclude those key sound effects from the speech track. The issue is closely related to issues with captioning and video description: it’s important to note certain sound events, since some conversations or events will lose meaning if the viewer is unaware of relevant background sounds.

On the whole, in my relatively brief examination of the updates to Section 508 standards, I’m happy with the results. Obviously, there’s always room for improvement — there’s still room for improvement in WCAG 2.0, which Section 508 could have changed — but I’d rather have a single set of base standards to reference than requirements which contradict each other! Working with standards isn’t the answer to every accessibility quandary, but you should never just ignore standards out of ignorance — instead, ignore them out of an educated disagreement.

Forthcoming Updates on Federal Section 508 Rules
Copyright 2004 – 2010 Joseph C Dolson, Accessible Web Design

It is in beta, of course, so it may not function entirely perfectly — in my installation, I had trouble getting a few features to work properly. I couldn’t get the cursor view to do anything at all, for example, nor could I get the cursor tool to turn on using F5, as the documentation describes. The Code view only seemed to show the text values for links — and nothing elsewhere. (For reference, this is on Windows Vista using Firefox 3.6.3.)

Nonetheless, I can see the potential for this software as a helpful tool for exploring both the accessibility of an interface and the awareness of a browser concerning that information. It’s a good idea, and with feedback is likely to become a useful tool, as well!

Steve is asking for feedback, so be sure to install this in your environment and take a look.

Accessibility Viewer Application Beta from the Paciello Group
Copyright 2004 – 2010 Joseph C Dolson, Accessible Web Design

Of course, the lack of support does have some consequences. We can’t just go out writing HTML 5 without having significant awareness of this lack of native support — we have to compensate.

Nonetheless, being able to incorporate great new elements like figure, progress, meter, nav to improve semantics or browser capabilities including content prefetching to provide a faster, more seamless experience for users is actually pretty exciting.

HTML5 Datetime input in Opera 10.53

But new input types…cold shivers.

Sadly, they’re also one of the less useful elements at the moment. Until support is available in browsers, they’ll simply fall back to a text field, unless supplemented by scripting to customize their behavior. But hey — easy upgrade, right?

From an accessibility perspective, this is fabulous news. Or rather, potentially fabulous news. These new input types — including date formats, time formats, numbers, ranges, and colors — are intended to provide user-friendly and accessibility-enabled interfaces for inputting these kinds of custom data. Ultimately, they’ll provide replacements (or fallbacks) to the innumerable JavaScripted widgets used to create date input or color selectors. Users, instead of encountering a different style of calendar every time they need to enter a date, could have a consistent user experience. Having the behavior built directly into the browser, and tied from there directly into any accessibility software in use offers a hugely more dependable experience for users of assistive technology.

Now, this all depends on several factors: vendor implementations need to meet user agent accessibility guidelines; interfaces between browsers need to be consistent; and, of course, the attribute values need to be implemented by enough browsers to make their use truly valuable!

Today, support is pretty limited. You can take a look at Roger Johansson’s HTML 5 input type test page and see whether your current browser supports any of them. If you’re using recent versions of Opera or Safari, the answer will be yes — otherwise, you won’t be seeing very much of interest for a while.

But you can implement these input types today.

All of these different input types fallback to a simple text input. If you’re using the HTML 5 doctype, there’s nothing stopping you from applying HTML 5 input types right now. Any browser that doesn’t support them will simply provide a field to enter plain text — so if you’re currently collecting email addresses in a text input (which seems pretty likely,) then you have no excuse not to change now. You may not see the benefits right away, but why wait? You’re not going to see any downsides, either.

Creating forms has long been a thorn in many a developer’s side. Dealing with how to best layout and collect date information, for example, is always a pain. Do you leave it as a simple text field, and have to deal with who-know-what kind of data received from the user? Do you use multiple select boxes, and force the user to walk through three or more fields just to enter the date? Do you use a JavaScript-based tool to provide a calendar, which may not have great accessibility, may behave strangely in some browsers, and may take a lot of development time to massage into providing the functionality you’re looking for?

Even when browser support for HTML 5 input types is fully available, it’s entirely possible that you’ll want to take the route to custom develop interfaces for various fields. However, unlike the past, you’ll only be needing to do this because something particularly unique is required for the project; for lower-budget projects, you can save a lot of labor and provide a solid interface just by using native features.

HTML 5 has cool stuff: new input types!
Copyright 2004 – 2010 Joseph C Dolson, Accessible Web Design

The specific repercussion will be that every implementation of a plugin will need to be registered with Twitter as a separate application.

This means that the development of WP to Twitter will need to move in a slightly different direction. After pondering a bit, I’m left with four plausible choices:

1. Let the plugin die
2. Implement OAuth for the plugin
3. Build a pass-through web service to act as an application interface with Twitter
4. Associate with a 3rd party web service in the same capacity

These all have downsides, obviously — but I want to lay out my thoughts on each possibility and I’m asking for comments from the users of my plugin on their preference.

Death of WP to Twitter

Although it’s not really my favorite option, I have to acknowledge that it’s plausible. It’s certainly the easy answer — maintaining an even moderately popular WordPress plugin is a lot of free labor. I already spend more time on maintaining than I really should, from a financial perspective, and this may push it over the edge.

Implement OAuth

This would be a fair amount of work for me, although not insurmountable. The real downside to it would be how much work it would be for users — every one of you would have to register one application with Twitter for every site where you installed the plugin. With one site, this may not be a big deal — but I know it could be a real pain for people with more than that.

It’s not without some potential advantages, of course – when you’re registering your own application, you could customize the application name, the home URL for the application, etc.

Build a pass-through service

One way around the Oauth mess is for me to build a separate service which would handle actually connecting to Twitter. WP to Twitter would authenticate with that service, and pass the post off to Twitter. Again, this would be a lot of work — but, more significantly, it would involve some definite expenses.

I’ve been happy to maintain this plugin for not-much-better than free, but when it comes to incurring expenses, I start to feel a bit unexcited. It’s not like WP to Twitter is a commercially viable business, and I have expectations of profit from it — but I’d prefer not to find myself going into the hole because of it. I’d probably need to see an increase in donations to make this feasible.

Use a 3rd Party Service

Obviously, if I can build a service to connect with Twitter, so can somebody else. This is almost certainly the easiest solution which keeps the plugin usable — but it does mean creating a dependency on a 3rd party to keep the plugin functioning. Depending on Twitter is just natural; obviously, if Twitter goes away, the point of the plugin is lost. Depending on somebody else is something I’m less certain of, on the whole. There’s a reason, after all, that the plugin allows for use of URLs without an external shortener.

Give me your thoughts

This is very important to me — I want to know what direction you’d like to see WP to Twitter go. Please let me know! Do you know another solution? Do tell!

And if there are no responses…well, that has a pretty obvious meaning as well.

The future of WP to Twitter
Copyright 2004 – 2010 Joseph C Dolson, Accessible Web Design

Interestingly, the most frequent complaints I’ve heard since launching it were in an area which I had considered to be the least important area of the plugin — what it looks like.

I only did minimal work in setting up the appearance for this plugin; checking whether it basically worked in the default WordPress themes and little else. My assumption was that if anybody needed the plugin, they’d just have to be prepared to customize it to meet their needs. There was no reasonable way I could set it up to mesh with all possible themes, after all!

But apparently, in order to have the plugin be generally accepted, people need it to have “a look.” Most advanced users will probably change it; but I clearly hadn’t considered the more beginner users, without sufficient CSS knowledge to readily customize the output.

What’s really interesting to me about this situation, however, is not whether the plugin is accepted, popular, or heavily designed; that’s just an example. I was intrigued to observe in my own development process an approach which almost entirely ignored what the product looked like. From start to finish, I was really thinking about whether the plugin produced well-structured HTML and whether the various functions involved in producing information worked well.

I just never thought about design. And why would I? If I can’t predict what context the plugin will be used in, why should I design it at all, beyond making the basic functionality clear?

It’s an interesting question; from my perspective, as a fairly advanced WordPress developer, I honestly prefer plugins I use to have absolutely minimal styles, and for me to be able to disable those styles at will so that I can replace them. However, WordPress has a very broad user base. Most of those millions of users probably expect that they can install a plugin and immediately make use of it — and any changing of colors or reskinning to better match their design is purely optional. For those users, I really should be providing something which can be immediately useful.

It actually does come down to usability: advanced users can do what they want with the calendar design regardless of how extensively I’ve set up styles. Beginning users, however, may not be able to fix anything that I’ve left unresolved, or not fully tested. In order to provide the best usability, I need to consider those users, as well.

Having determined that it does make sense to actually design the plugin’s output, but also knowing that there’s no reasonable way I can design it to match all themes, I do have to make a firm decision about what the basic color scheme for the plugin will be. Originally, I’d used a basic, Kubrick-derived color set. Now? Well, the sensible thing seems to be to consider branding; set it up using my own website’s color scheme. It may be subtle, but it will convey my identity, even without my name or URL. That seems worthwhile.

Guess I better get to work!

Form over Function? Never thought about it…
Copyright 2004 – 2010 Joseph C Dolson, Accessible Web Design

Version 1.3.0 released. Numerous bug fixes and new features.

I just launched the first public draft of an online calendar plugin I’ve been working on for a while. It’s based on a plugin from Kieran O’Shea, Calendar, but has been adapted extensively to better suit my own needs.

Hopefully, it’ll also suit other people’s needs.

• Read more about My Calendar.
• Download My Calendar.
• View a sample installation.

Please leave comments or questions at the My Calendar support page; leave feature requests on the feature request page!

New WordPress Plugin: My Calendar
Copyright 2004 – 2010 Joseph C Dolson, Accessible Web Design

And, naturally, it always fails. Something goes wrong in the system; gross negligence of maintenance causes a malfunction; or some unanticipated exception allows the hero to escape.

This is an important thing to keep in mind when designing or building a web site, in every aspect. When you think you’re adding fabulous new functionality or greater accessibility, you should always be thinking about whether you’re ultimately supporting your visitor’s needs — or just making your system needlessly more complex.

Jared Smith, from Web AIM, recently published an article on web accessibility preferences expounding on the notion that in most cases, providing tools for your disabled users to change their experience usually means that you haven’t done your job right in the first place. Perhaps, rather than adding a tool to enable people to adjust your site, you should simply fix the site. Jared makes the very good point that in most cases, the people who need text enlargement have already taken care of it through their browser settings or operating system; and those who need extreme enlargement can’t be helped by a common accessibility widget — they need software support.

So, given this case, what do you actually accomplish by adding accessibility widgets to a web site?

If you’ve added them to a global element, to make them available throughout the site, you’ve made your site more complex: there’s more information on every page which needs to be sorted through or skipped over. You’ve added an additional technical element which needs to be supported and maintained — as browsers change, you’ll need to be rechecking not just your default settings, but all of the various combinations you’re providing, as well.

If you’ve added the same options to a page dedicated to these accessibility options, you’ve pretty well avoided the problem of having a globally more complicated interface. However, you need to ask yourself whether the problems your accessibility options fix will prevent the users who need them from finding the options! Take this example: you’ve chosen a relatively low-contrast (but attractive) text color for your footer and secondary header navigation. Since this color is below the WCAG 2 color contrast requirements, you’re providing a link to a page where the user can select a high-contrast option.

Unfortunately, since the link is in your footer, that user who needs a high-contrast page can’t actually find the page where they can make the change.

Problems with site complexity don’t only effect web accessibility, however. Any additional function to your web site needs to be carefully considered before implementation: is it worth while to add an audio player with auto start to your home page? What are the consequences of making this change? You may think that it’s a great opportunity to immediately promote your band’s music to those who want to hear it; but you’re making the gross assumption that those visitors want to hear it right now. They may not. And if they’re in a sensitive situation — checking you out from their quiet office cubicle, for example — then their first reaction is likely to be “How do I turn this off!”

Assuming you have decided to add this audio player to your web site — you may not realize that the most important control you need to have is a prominent STOP button. Otherwise, the most natural way to stop the music is to leave your site.

Any piece of new functionality adds complexity to a site. It may create an undesirable reaction, it may create user confusion — or it may be a brilliant idea which turns your home business into a multi-million dollar corporation. You shouldn’t avoid adding functionality on the grounds that anything complicated is going to be a problem; but you should certainly take a very close look at every new feature and decide whether it will add to the user experience. When making that decision, the points to consider are not limited to the value of that feature alone. You need to also consider all the other features which will be simultaneously available; you may want to add a new feature, but move an existing one. It’s usually not any given feature which causes problems; it’s having too many paths to follow which may confuse your visitors.

When More is Less
Copyright 2004 – 2010 Joseph C Dolson, Accessible Web Design

Thanks to the power of internet criticism, the code discussed in this blog post has since been fixed! Sometimes just making a complaint is all it takes to get something fixed. I was highly critical of the code authors for this low-quality code; but they truly did care, and made changes. Thank you.

Authoring forms is an important part of keeping the web fully accessible — not just providing access to information, but allowing users to fully interact with the web in all it’s glory. Interactivity is what makes the web powerful and persuasive.

As such, I can’t help but be frustrated when I run across basic form construction which is simply well below the standards I’ve come to expect. A form like this one, for example, is incredibly irritating to my sense of what the web should be:

  <form action="/store/add_event_to_cart/53" autocomplete="off" method="post">    <table>
  <tr>
    <td nowrap><span class="required">First Name:</span></td>
    <td><input id="attendee_first_name" name="attendee[first_name]" size="40" type="text" value="" /></td>
  </tr>
  <tr>
    <td nowrap><span class="required">Last Name:</span></td>
 
    <td><input id="attendee_last_name" name="attendee[last_name]" size="40" type="text" value="" /></td>
  </tr>
 
...[numerous similar fields deleted to avoid boring the hell out of you]...
 
  <tr>
    <td colspan="2">&nbsp;</td>
  </tr>
  <tr>
    <td colspan="2">
 
      <input name="attendee[sponsor_email]" type="hidden" value="0" /><input checked="checked" id="attendee_sponsor_email" name="attendee[sponsor_email]" style="vertical-align: top;" type="checkbox" value="1" />
      <p style="display: inline-block; width: 360px;">Please sign me up to get occasional information from select sponsors, partners, and other fun people.</p>
    </td>
  </tr>
    <tr>
    <td colspan="2">Discount code (if applicable): <input autocomplete="off" id="attendee_discount_code" name="attendee[discount_code]" size="10" type="text" /></td>
  </tr>
    </table>
 
    <input name="commit" type="submit" value="Add Attendee" />
  </form>

But in this case, it’s not just the nature of the form itself. There’s a lot wrong here — the use of table for layout is a big problem, but even if you’re accepting the table as logical (and there is a particular logic which would except tables for forms,) the lack of a summary or headings in that table and the use of empty table cells to provide spacing is a big problem. Then we look at the form itself — not a label element in sight; instead we have plain text using a span and class to indicate if a field is required. There’s no coded indication that a field is required; it’s a purely visual indicator.

My sense of accessibility hurts.

And do you want to know where this code came from? Here it is.

Here are a few good articles on high quality form construction – but don’t bother reading them. After all, they didn’t.

• Sensible Forms
• Pretty Accessible Forms
• Making Compact Forms more Accessible

This is something that pisses me off; but you can find it everywhere. Large organizations responsible for web publishing don’t always maintain the standards they talk about. Is it just talk, then? Does the fact that An Event Apart does what A List Apart condemns mean following standards and implementing accessibility doesn’t mean anything?

Thankfully, no. It does mean that web sites aren’t perfect; and the people doing the labor are frequently not the people who know best how it should be done. But it is a problem — as much as we can evangelize best practices, it doesn’t mean that they’ll be used.

There’s a lot of pressure in the web industry to produce fast results. Sometimes this means people take shortcuts; sometimes it means hiring people who may not be as fully trained or qualified as you really wish you had; and sometimes it means things just go wrong.

But I’m left with a definite feeling of frustration to find that a leading web standards event like An Event Apart should exhibit this kind of HTML on their web site.

How can this be avoided?

Ooh, that’s a tough one. Work processes, new employees, insufficient testing — all of these can allow inferior code onto a site. As a freelance designer, it’s positively rare that I have sole control over new content or template changes after the initial launch. As a member of a team, I can only imagine that it’s even more difficult — anybody with sufficient permissions to commit a change can change the overall level of competency exhibited on the site.

Application of a tool like Marco Battilani’s Big Red Angry Text technique can help, but it’s a little scary to put into a published site if you know that the editing won’t always be done by knowledgeable people. It may demonstrate mistakes, but can sometimes serve to do nothing more than piss off or frustrate your client or staff. It depends on the control and education you’ve been able to impose.

1. Educate. Teach the people who will be doing work on the site as much as you can – the what and the why.
2. Review the site. Review the work that’s been done; a 30 second glance at the code is likely to result in fixing at least some errors, and will hopefully prevent future errors of the same type.
3. Provide tools for self-checking. Not a first choice, since all automated tools are flawed by their very nature, but they can still be of use.

It’s not always practical; but if following these steps is at all an option, it’s really worthwhile.

When the right hand doesn’t listen to the left.
Copyright 2004 – 2010 Joseph C Dolson, Accessible Web Design

First, sources:

Americans with Disabilities: 2005

The primary source for statistics in the Practical eCommerce article was a report called Americans with Disabilites: 2005, produced by the United States Census Bureau. The data dates to 2005, but the report was released in December of 2008, so it’s not far from the most current information available which is based on truly extensive research.

This report was released from data gathered in the Survey of Income and Program Participation in 2005, updating the information from a 2002 report of the same name. The report is limited to the civilian, non-institutionalized population of the nation, and estimates that the overall percentage of the population demonstrating disabilities would rise to 15.7 percent from 15.1 percent if that population was included, referencing information from the 2006 American Communities Survey.

The American Communities Survey

The ACS is a continuous data collection effort by the U.S. Census Bureau used to produce annual estimates at the national, state and local level on the characteristics of the United States population. In 2005, the ACS collected information from approximately 3 million addresses in the United States and 36,000 addresses in Puerto Rico. In 2006, it will also include 2.5 percent of the population living in group quarters, (U.S. Census Bureau, 2003).

Given the rapid pace of technological development, access to ongoing current statistics is of inordinate value to internet-based businesses, although the data is not currently detailed enough to be fully appreciable in web accessibility.

There is a more recent report, from the 2006 American Communities Survey, but the data collection is organized differently, so I elected not to mix the two to avoid introducing errors caused by relating data sets which are not a definite match. Regardless, both sets of data include valuable information, and are well worth consulting.

The primary flaw in this period of American Communities Survey data is that it does not break out separate types of sensory disabilities; blindness and deafness are collapsed into a single category. Although both of these issues have a bearing on web accessibility, the response to the issues is so radically different that this is a major flaw in the data when it comes to web accessibility analysis.

More recent American Communities Surveys have broken this information down further. As of the 2008 questionnaire (downloadable from the Census website), sensory disabilities are separated between blindness/low vision and deaf/hard of hearing.

Cornell University: Disability Statistics

A third fabulous source for disability statistics (with easily the best interface of the group) is the Disability Statistics project at Cornell University. The data is sourced from the American Communities Surveys and the 2000 United States Census, along with a few additional sources, so the base data is the same, but a greater variety of perspectives are available.

The Cornell database requires an account to access statistics, but they do provide free access using a public “guest” account. The email and password entered for the guest account are both “guest.”

Issues with the Data

It was necessary, of course, to summarize the data used for the report. However, each of those numbers should be viewed in context, as well. All of the data referenced is accessible as a Excel download from the U.S. Census Bureau (linked above).

The data is excellent for gaining an overview of the disabled population of the United States, but is not specific enough to give a clear sense of whether these disabilities will impact your web site. The statistics from the American with Disabilities report clearly state, for example, that 3.4% of individuals over 15 years of age have difficulty seeing; a total nearing 8 million people. However, exactly what is included in the data is hard to specify. The information was gathered by asking a series of questions, gathering whether the person had difficulty reading newsprint, etc. It doesn’t specify anything about the nature of the problem.

In general, my assumption is that the data may include some individuals who struggle with reading due to dyslexia, dependent on the exact phrasing of the questions, but not all, and presumably includes no or very few individuals with color blindness.

Download the reports (all in PDF format):

• Americans with Disabilities: 2005
• Disability Status and the Characteristics of People in Group Quarters
• 2006 ACS Content Test Evaluation Report Covering Disability

United States disability statistics: Measurement and sources.
Copyright 2004 – 2010 Joseph C Dolson, Accessible Web Design