Advanced Tips and Training for Web Accessibility

U Washington technology accessibility specialist Terrill Thompson offers tips for improving accessibility on education portals and rich Internet applications.

• By Dian Schaffhauser
• 07/14/11

University of Washington technology accessibility specialist Terrill Thompson divides his time among multiple grant programs, including AccessIT (the National Center on Accessible Information Technology in Education) and DO-IT (Disabilities, Opportunities, Internetworking, and Technology). These federally funded research and dissemination projects focus on improving access to technology, education, and challenging careers for individuals with disabilities. Prior to his work at U Washington, Thompson served as coordinator of assistive and information technology at North Carolina State University.

Don't miss part 1 of Campus Technology's interview with Thompson: "Web Accessibility for All."

Campus Technology: What are three simple things developers can do to make their Web portals more accessible without too much hassle?

Terrill Thompson: Good semantic structure overall. If it's a heading, use an HTML heading. If it's a list, use an unordered or ordered list. Use HTML markup the way it was intended to be used. Communicate structure and make sure your code is valid. All of that goes together, I think.

CT: How about three hard things that developers should absolutely tackle?

Thompson: If a site has widgets or any sort of rich, dynamic content, then it's time for developers to understand and embrace ARIA, the W3C standard: Accessible Rich Internet Applications Suite. It's a draft specification of markup that gets added to the HTML that allows things like roles, states, and properties to be communicated to assistive technologies. Then the assistive technologies figure out the best way to deliver that content in a meaningful way for the user. Web sites have historically been static, and so they didn't have any sort of mechanism for that kind of communication. Now we've got Web sites that are behaving more and more like applications.

ARIA provides a layer that is similar to what has existed within the operating system level. It allows information about dynamic, rich, interactive content to be communicated through the browser to the assistive technology user. It's a fairly complex specification, but if people are developing content that's rich and dynamic, then the site really needs to use ARIA.

CT: Can you give an example of how ARIA is used?

Thompson: Let's say you delete something, move something, or add something to your portal page, and then a message appears at the top of the screen that says that was successful or that was not successful. If you can see, that's great; you've got that communication. But imagine that you're a screen reader user and you just performed that behavior and this message happens somewhere entirely different on the screen. If you don't see that, then how are you going to know it happened? With ARIA you can assign a role to an alert for that alert box. That informs assistive technologies that this is important content that users need to be informed of right now. The assistive technology will then announce the content of that alert box, and the user can continue on from wherever he left off. Since ARIA is a draft spec, it's not fully supported yet by either browsers or assistive technologies. It's kind of hit and miss as to what's supported and what's not--but that particular feature is pretty well supported.

CT: Share an anecdote about something accessibility-related.

Thompson: I've seen institutions that have added accessibility, and then they go through a redesign and the accessibility suddenly disappears. You hate to see that happen. You like to think that accessibility is part of the infrastructure. I think policies can help there, and leadership really stressing that accessibility is important can help.

The people who contact me most regularly are the folks who are working on the portal at the University of Washington because they're implementing some new feature and they want to figure out how to do it in an accessible way. For example, they implemented a tag cloud, and were concerned about its accessibility. It's kind of a visual thing--lots of tags, and some are bigger than others. They actually did implement a version where they added, I think, a title attribute that gave some indication of the size of something relative to the things around it.

That seemed like a good effort. There are lots and lots of tags in this list--20 or 30 tags. It's not a very usable experience for somebody to go through that list audibly and listen to the size of all these things and then have to sort it in his mind to figure out which ones are the biggest and which ones are the smallest. So a better approach might be to sort it--to have an option where the tags are sorted by size, so the bigger things are on the top and the smaller things are on the bottom. Then the screen reader user can access it that way, and maybe other users would like seeing it rendered that way too.