Next Generation Web Accessibility Tools are Critically Needed

Share on FacebookShare on LinkedInShare on Twitter

This ain't your older brother's web any more

Web pages used to be relatively static affairs, some were generated by server side applications, some stored in content management systems. But because of the browser wars, developers were loathe to use too much JavaScript for fear of having products that would only work for half of their users.

Of course, where there is a problem or a void, something will appear to fill it and JavaScript frameworks like Scriptaculous, jQuery and Dojo appeared that made it easy to develop cross-platform rich applications. The result of this is that it is now more common to encounter web sites that have JavaScript than web sites that have no JavaScript and there are many popular rich applications like Facebook that are written almost entirely in JavaScript.

The result of this is that whereas it used to be possible to find the totality of a web site or web application by going to the home page, fetching the HTML content, pulling out the HREF links and then following those until you find no more links that you have not yet seen, that is no longer enough.

JavaScript is now being used to manipulate web pages on the fly, generating new content, removing and changing existing content, adding event handlers dynamically. You can spend hours having a rich interaction that is generating many megabytes of content within the browser and never change the URL displayed in the location bar of your browser and without ever refreshing the page. Just watch my kids on Facebook to see what I mean. In addition to that, there are now server-side applications that generate new URLs every time you visit a page, so relying on the URL as an indicator of whether you have encountered this page before is also not reliable.

The death of the href and the dumb spider

For first generation accessibility tools, this has the following implications:

  • Spidering, by following URLs gives you only a part of the picture - because many applications redirect to URLs based on event handler logic, many of the URLs that make up a site or an application are not discoverable by looking at the HTML of the page. A spider therefore gets a partial picture of an application's URLs when it does this.
  • Fetching URL content is not enough - even if you know all of the URLs that make up a site, fetching the content once from those URLs does not give you access to all of the content that a user would encounter on that page. You have to exercise the JavaScript on the page in order to get it to generate the content so it can be evaluated.
  • Looking at URLs for testing uniqueness is not enough, the content needs to be evaluated to determine whether it is unique or not.
  • Development of a single "web page" application can take months of work by a team of developers. The code that is used by the site might be hundreds of thousands of lines of code. Doing an evaluation of this "page" in the quality assurance phase after it has been implemented is too late to impact the first release. Also web accessibility tools need to support the workflow of multiple developers and testers working on a single page or application.

These implications mean that a second generation of web accessibility tools is needed to help us to develop and evaluate the accessibility of our web sites and web applications. These tools need to do everything that the old automated tools were able to do and more.

  • They need to be fully JavaScript aware
  • They need to be able to track and evaluate dynamic page updates
  • They need to be able to record, play and replay sequences of JavaScript events and they need to intelligently evaluate the content and the resulting issues.
  • They need to do this for developers while they are developing, for quality assurance engineers while they are doing functional tests and for web site managers while their application is actively deployed.
  • They need to support the work of the individual developer or tester as well as the collaborative work of a development team.

More on this later...

About 

For over fifteen years, Deque has been helping major corporations, government agencies, and other organizations ensure that their websites and mobile apps are accessible to everyone. We have more than fifteen years of history of serving the federal government, including undertaking the biggest accessibility program that's occurred in the United States government or anywhere. Deque also works with .edu's and mission-focused nonprofits to ensure that their materials and systems are usable and barrier free for users with disabilities. The company invented the first accessibility plug-in software, the first web-based testing platform, and the first server-based accessibility solution. All of these have been created in the service of helping our customers become accessible, advance the goals of their organization, and remove barriers for all users on the web.

Leave a Reply

You can use these HTML tags:

<a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>