Portals | Q&A

Web Accessibility for All

• By Dian Schaffhauser
• 07/07/11

When a Web designer or developer at the University of Washington in Seattle has questions about the accessibility of the school's sites and applications, he or she can tap the expertise of a team of technology accessibility specialists such as Terrill Thompson. As a senior computer specialist, 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 IT at North Carolina State University.

Campus Technology talked with Thompson about the importance of accessibility for all campus constituents and common pitfalls to avoid when creating accessible online sites.

Campus Technology: What are the hurdles that some students and staff face in using a portal or a campus Web site?

Terrill Thompson: Everybody interacts with the Web in different ways. Historically, a lot of design has been centered around what the developer or the designer thinks should be the optimal experience. But developers don't necessarily consider all of the different ways that people are interacting. So you've got people who use different browsers, of course, and people on mobile devices, desktops, and laptops. We also have people with very different needs in terms of screen resolution, font size, or color schemes. We have people who don't perceive content visually at all; they may have a visual impairment or may be entirely blind and use an audible interface such as a screen reader or a tactile interface, which is a Braille device. We've got people who can't use a mouse, for physical reasons or because of a device they're using--maybe they have a touch screen or use speech input and operate the computer that way. So there are all these ways that people interact with content, and there are standards that have been developed to ensure that Web sites work for all the different users that are out there.

CT: Why is it important for a school to get Web accessibility right?

Thompson: There are legal obligations, certainly. Schools are not supposed to exclude students from being able to access resources--particularly portals, which are critical for access to all the things that one needs in an academic experience. Every student needs to be able to access that. If a student is using a screen reader, then the portal has to be accessible to him. If he can't use a mouse, he still needs to be able to operate all of the features and controls and access links and so forth.

CT: What should an institution's primary goals be when designing an accessible portal?

Thompson: Schools should define their target in terms of accessibility standards. We have a set of standards now that we're all turning to: the Web Content Accessibility Guidelines version 2.0 from the W3C. Those guidelines are divided into different levels of success criteria: Level A, Level AA, and Level AAA. Campuses need to identify which level they're shooting for on their Web content--particularly for things that are integral to the programs and services they're providing. You can throw the portal into that category. Schools need to clearly state, "We're going to shoot for WCAG 2.0 Level AA and do everything we can to make sure that we conform at that level."

CT: Where do you think most institutions are right now on that scale of success?

Thompson: Not compliant. There are quite a few institutions that have Web accessibility policies that state they're shooting for Section 508 compliance. Technically, Section 508 requires that federal agencies have accessible information technology, and it doesn't explicitly apply to higher education institutions or to states; it's a federal law. But since it's the only set of accessible technology standards written into the law, it stands to reason that it would be a set of standards that folks feel compelled to comply with. The current version of Section 508 is based loosely on Priority One checkpoints from WCAG 1.0, [the previous version of the WCAG standards]. [The feds] are currently working on revising those [Section 508] standards so that they will ultimately be more in line with WCAG 2.0.

CT: Is a portal different from a standard Web site in providing challenges to users with physical limitations?

Thompson: I think as a Web site or a Web application, a portal is subject to the same issues and concerns. If a person is using a screen reader, for instance, he's not able to see graphics. So if there is information being presented using images, then it needs to have alternate text so screen reader users have the same access to that information that sighted users have access to.

Our internal portal at the University of Washington is divided into different sections. You essentially have several boxes that contain different types of content. It's key to make sure that people understand that structure, so if somebody can't see it, he knows to move from box to box and understands that each box contains related content. So having headings at the tops of those boxes is an important consideration.

Typically, portals do that sort of thing; they'll have what appears to be a heading. But if that's just big, bold text that isn't explicitly marked up as a heading in code, then screen readers aren't going to be able to recognize that it's a heading and will not be able to communicate that to users. Screen readers have functionality that allows users to hop from heading to heading to heading, so they facilitate navigation by communicating what the structure of the page is.

CT: Can you share a few of the common blunders that you see institutions making in terms of accessibility?

Thompson: Headings certainly have been one that's important. They've been around since the early days of HTML, but it's still very common for pages to not use headings or to not use them well. One study came out a little over a year ago--longitudinal research--where we looked at the home pages of higher education institutions in the Northwest. We did a follow-up analysis a few years later to see how things had changed. There were actually improvements in headings.

The one thing that got worse over time was keyboard navigation. There are lots of Web sites now that you can't access without a mouse, and there are quite a few users who are unable to use a mouse physically--and also that affects people who don't have a mouse because they have a touch screen. So that may be the most prevalent blunder now. We're adding a lot of rich content, things that happen on the page using Ajax or JavaScript--dynamic menus that drop down or fly out as you hover over them. But if we don't have the means of hovering [because we don't use a mouse], we don't necessarily get those menus. Then the question becomes, do we get the content some other way or are we just completely excluded from being able to navigate the site?

I think portals are guilty of having dynamic widgets, where you can drag and drop things around on the screen, reposition boxes, or do other sorts of behaviors that are mouse-dependent. Then the question becomes, if somebody is not able to use a mouse or doesn't have access to a mouse, can he access those same features in some other way?

If not, maybe that's not critical; maybe those features are just add-ons. They're nice features, but they're not really critical to using the site for its intended function. We talk about progressive enhancement where we build a site that's fully accessible--but with no style sheets, no JavaScript. Somebody can access the core site and have full access to the content, understand the structure, and use that site in a meaningful and helpful way. Then we enhance that by adding a style sheet to make the site look a certain way and adding JavaScript to make it behave a certain way. But that behavior isn't going to exclude the people that only had access to that core site to begin with. It just enhances the experience for people who do have a mouse or who are able to benefit from those enhancements.

CT: So accessibility isn't something to do as an afterthought, to add on after the site is built?

Thompson: No. A lot of people say that it is a lot more cost effective to build in accessibility from the beginning rather than to have to go back and make things accessible later. As I provide accessibility support, what I encounter most often is that there are some things that need to be done for accessibility that are show-stoppers. If you've already built this application and now you try to make it accessible, you're going to encounter some features you have to scrap or do in a completely different way in order to make it accessible. Whereas, if you'd thought about accessibility from the beginning, that's not going to be the case. If you build a completely accessible application from the ground up, you've got no fears.