Skip to main content

Accessibility and Legacy Browsers

Web Accessibility in Organizational Environments

The technology used to build accessible web and cloud applications is the same inside or outside an organization. However, the group of users served by the application may be quite different. For example, the IT department of your organization likely only supports a limited set of operating system versions, browsers, and Assistive Technology (AT) products. Contrast that with the situation on the Internet, where any user with any combination of these technologies may visit your site. When building an application for your employees, you need to consider IT profile of your company. 

Web application accessibility is a rapidly evolving area, and browser and AT developers are adding new features to support web application accessibility in each new version. Globally, about 12% of computers in large commercial organizations are still running IE6.  But, if your organization is one of them, you may have a large percentage of your users running a browser that is missing accessibility features, compared to the low teens for the general population. If you have many users with an older browser or AT product, you will need to develop your accessibility solutions in a way that works for them, while taking advantage of newer features for any users who do have newer browsers that support these technologies.

For web applications, a key technology is the Accessible Rich Internet Applications (ARIA or WAI-ARIA) spec from the World Wide Web Consortium (W3C). At the time of this writing, ARIA is supported in Microsoft Internet Explorer 8 and later, Mozilla Firefox 1.5 and later, Opera 9.5 and later, and Webkit. Many popular commercial AT products support ARIA, as do a few free ones. However, a great many older, simpler, or more niche AT products do not support ARIA, or do not support it well. In determining how much your organization can rely on ARIA, you need to consider both the browsers and the AT in use within your organization.

Another important consideration is whether your organization can support scripts. While all of the major browsers have supported script since the late 1990s, many older, simpler, and niche AT products either don’t support script or have poor support for script. In addition, some organizations disallow scripts for all users for security reasons. 

This article will teach you how to take advantage of newer features for your users who need them and have technology that can take advantage of them, while still providing as accessible an experience as possible to your users with older technology.

Functional Web Accessibility

Functional Web Accessibility means that you begin making your User Interface or controls accessible by understanding what their functions are: what does the user do with it? What are the inputs? What are the outputs? Once you understand the functionality, the next step is modeling that functionality HTML and ARIA. 

In general, if there is an HTML control, such as a button, link, list or form element, that is close to the function of your control, you will save a great deal of development time and money by using it rather than building your own. In addition, the controls that are part of the browser have accessibility functionality built into them, which you will have to build if you create your own. Using HTML controls and combinations of HTML controls, and following careful coding standards creates sites that are also accessible in older browsers that do not support ARIA. Sometimes doing this will require design changes. It is important to understand that the cost and complexity of development can increase rapidly when you build custom controls, and that you will need to make appropriate trade-offs in design and presentation.

Flow chart for functional accessible design of web controls described in the following section

Step 1: Document what the user does with the control

Step 2: Document the user inputs

Step 3: Document the feedback given to the user

Step 4: Determine whether there is an HTML control that supports the function, input and output documented in Steps 1-3

Step 5: If there is an HTML control that supports the function, input and output, determine whether it can work in the design of the application

If there is not an HTML control that supports the function, input and output from Steps 1-3, but there is one that is close, use the control plus additional ARIA, and determine if the control plus ARIA can work in the design of the applicaiton

Step 6: If the control cannot work in the design, can the design be changed to accommodate the control?

Step 7: If the design can be accommodated, use the control

If the design cannot be accommodated, or if there is no HTML control that supports the function, inputs and output from steps 1-3, then determine whether the function, input and output can be supported with ARIA. 

Step 8: If the function, inputs and outputs can be supported with ARIA, build a custom control and use ARIA to make it accessible.

If the function, inputs and outputs cannot be supported with ARIA, the control cannot be made accessible, and will need to be redesigned. This is not a common situation.

Browsers and AT, Old and New

There are several general approaches to developing applications that work for a variety of users and configurations. 

Multiple Versions. The developer creates multiple, separate sites or versions of the site. Sometimes this is called an “accessible mode” or “more accessible mode.”  Alternatively, users with accessibility needs might be sent to a version of the site designed for older or mobile browsers, sometimes called a “lite” or “downlevel” version.  This approach is easy to understand, but it has some drawbacks. It may not be possible to implement all the features using the technologies available to the downlevel version. Downlevel versions also get fewer hits, and so may get less attention and resources for testing, bug fixing, and implementation of new features than the “main” version. Because of these two issues, some users feel that they are not getting the same experience as everyone else. Finally, multiple versions means multiplying your cost, as each version must be developed and tested separately, and the added complexity of switching between versions or modes.

Graceful Degradation.  The developer creates a site that uses newer features and technologies, and takes some care to have something reasonable happen when those technologies and features are not available. The assumption is that the version with the newer technologies and features is the “main” version, that not having them is an error case to handle gracefully. 

Progressive Enhancement.  The developer creates a site that is fully functional without newer features and technologies, but layers on additional functionality or style in a way that makes the site better in some way, without changing the underlying functionality. This approach is similar to graceful degradation, except that it assumes that the version without the newer features is the main version, and the newer features are only there as an enhancement.

Universal Development.  The developer creates a single experience that works for everyone. There are no modes, degradations or enhancements for subsets of users. If all of the browsers and AT in your organization support script and ARIA, you can create a single version that relies on these technologies and works for all of your users. If all of your users have script enabled, but none have a browser/AT combination that supports ARIA, you will use the semantics of HTML and careful scripting techniques that allow scripted sites without ARIA to work for everyone. And, if your organization prevents the use of script for all users, with and without disabilities, you can build a static site that works the same way for everyone. This approach, because it removes multiple code paths, significantly reduces development and testing cost. In addition, users prefer it because everyone gets the same functionality.

The two technologies that have the most impact on the decision of which approach to take are script and ARIA. Script is how interactivity is added to web sites for mainstream users, and ARIA is how the functionality added with script is exposed to users of Assistive Technology.

Table 1:  adaptation approaches for different mixes of technologies
SITUATIONEXAMPLEAPPROACHDETAILS
No script for
any users
Script disabled by
policy or proxy
Universal development
  • Static pages with only links and forms
  • Accessible to all with good HTML structure
Script for most users, AT that doesn’t support script Some less expensive
or very old AT doesn’t support script at all
Progressive enhancement
  • Script executes for those that have it, but application works without it
Script for all users, no ARIA support Employees and other users within your organization are all on Internet Explorer 7 or earlier and script is not disabled
by policy or proxy
Universal development
  • HTML elements
  • Semantic event handlers
  • Model complex UI in HTML
  • Simplify design where needed
Script for all users, some browser/AT combinations have ARIA support Mix of Internet
Explorer 6 and
Internet Explorer 8
Progressive enhancement
  • Use the same strategies as script for all users,
  • no ARIA support
  • Layer ARIA on top
  • Test that things don’t break for those without ARIA
  • Our developer content provides a lot of guidance for this scenario
All users have browsers and AT
that support ARIA
Enterprise adopts
new browsers and
AT quickly
Universal development
  • Use HTML semantics or rely on ARIA alone
  • Custom controls marked up with ARIA
  • HTML modeling not required
  • But might be a good idea so that you can support changes in the situation without additional cost

 

Progressive Enhancement Samples

Situations with no ARIA support, with or without script are covered fairly well in the W3C WCAG 2.0 documentation.  Similarly, pure ARIA situations are covered pretty well by the ARIA Authoring Best Practices.

The following examples cover progressive enhancement to support both browsers with ARIA and those without ARIA.

Sample: Menu Bar

HTML

The HTML for the menu bar is a list element with a few child list items, each containing a link. This is a sound semantic approach to all hierarchical, flat or nested, groups of links, be they in a single list (toolbar), in popup child lists (menus) or in expandable lists (trees). The menus are represented as a nested list under the second list item. Note that even though the second list item link has an an onclick() event-handler which cancels the default navigation, there is an href value for the case where script is turned off.

The WAI-ARIA roles are a rule of "menubar" on the top-level UL element, a role of "menu" on the child UL elements that are popup menus, and a role of "menuitem" on each A HREF element within the menus. The aria-label property is set on the "menubar" to give it a friendly identifier for AT devices, and the aria-hidden state is set on the "menu" role elements.

<ul class="menubar" role="menubar" aria-label="Navigation Bar"







  onkeydown="OnMenubarKeydown(event);" onclick="OnMenubarClick(event);">







  <li class="first"><a href="File.htm">File</a>







    <ul role="menu" aria-hidden="true"







      onkeydown="OnMenuKeydown(event);" onclick="OnMenuClick(event);">







      <li><a role="menuitem" href="Open.htm">Open</a></li>







      <li><a role="menuitem" href="Save.htm">Save</a></li>







      <li><a role="menuitem" href="Print.htm">Print</a></li>







    </ul>







  </li>







  <li><a href="View.htm">View</a>







    <ul role="menu" aria-hidden="true"







      onkeydown="OnMenuKeydown(event);" onclick="OnMenuClick(event);">







      <li><a role="menuitem" href="Toolbar.htm">Settings</a></li>







      <li><a role="menuitem" href="Reset.htm">Reset</a></li>







      <li><a role="menuitem" href="Settings.htm">Settings</a></li>







    </ul>







  </li>







  <li><a href="Settings.htm">Settings</a>







    <ul role="menu" aria-hidden="true"







      onkeydown="OnMenuKeydown(event);" onclick="OnMenuClick(event);">







      <li><a role="menuitem" href="Account.htm">Account</a></li>







      <li><a role="menuitem" href="Permissions.htm">Permissions</a></li>







      <li><a role="menuitem" href="Settings.htm">Settings</a></li>







    </ul>







  </li>







</ul>

Script

The ToggleMenu() function is used to open and close the menu. After harmonizing the Mozilla and IE events, the child list element is located, and its display is toggled between "block" and "none", and the aria-hidden state is set to either true or false. If displayed, the menu is positioned using a helper function.

function ToggleMenu(evt)







{







  HarmonizeEvent(evt);







  evt.preventDefault();















  var src = evt.target;







  var menu = src.parentNode.getElementsByTagName("UL")[0];







  if (menu)







  {







    if ("block" == menu.style.display)







    {







      menu.style.display = "none";







      menu.setAttribute("aria-hidden", true);







    }







    else







    {







      menu.style.display = "block";







      menu.setAttribute("aria-hidden", false);







      PositionElement(menu,src,false,true);







    }







  }







}

CSS

The CSS for the menu bar turns off padding margin and list-style for the list element. The list item elements are floated left, so that they appear horizontally rather than in the default vertical list layout. The display property on the links is set to block so that the entire tool bar item is hot. Additional CSS for the menu itself, sets its position to absolute, its display to none, and its float to none.

/* menubar and menus */







ul.menubar, ul.menubar ul { margin:0; padding:0; list-style-type:none; }







ul.menubar li { float:left; border:1px solid; border-left:none;







  background-color:menu; color:menutext;}







ul.menubar li.first { border-left:1px solid; }







ul.menubar li a { color:black; text-decoration:none; width:100%; height:100%;







  padding:0.2em 2em 0.2em 0.5em; width:8em; display:block; }







ul.menubar a:hover { text-decoration:underline; }







ul.menubar a:focus { color:highlighttext; background-color:highlight;  }















/* menu specific */







ul.menubar ul { position:absolute; display:none; border:1px solid; }







ul.menubar ul li { float:none; border:none; }







ul.menubar ul li a { width:10em; }

Sample: Tree Control

HTML

The HTML for the tree is a set of nested list elements. Note that the ToggleTree() event-handler is bound to the <a href> element, and that the "+" alt attribute on the image. In this manner, the information for the actionable link contains the alt information from the image, indicating whether the list item is expanded ("+")or not ("-").

The WA-ARIA roles are pretty straightforward for the first two, "tree" on the toplevel UL element, and "treeitem" on the node items in the tree. For the child UL elements, the hideable tree node groups, a role of "group" is assigned, as these are not new "tree" elements, but "groups" (sub-trees, if you will). The most interesting of the WAI-ARIA roles, is that of "presentation" which is set on the LI elements whose child A HREF elements get the "treeitem" role. This role of "presentation" is required so that user agents ignore the semantic information of the LI (list item) element and go straight to the child A HREF elements as the "treeitem" nodes. This preserves the relationship among the "treeitem" elements, which otherwise are not siblings, strictly speaking, since each is under a separate LI element. The aria-expanded states is set to indicate that the tree node is hidden. It is toggled in script when the element's visibility is toggled.

<div id="treeBox">







<ul id="tree" role="tree" onkeydown="OnTreeKeydown(event);" onclick="ToggleTree(event);" >







  <li><a role="treeitem" aria-expanded="false" href="Documents.htm"><img height="9" width="9"







    src="img/tree-p.png" alt="+" />Documents</a>







    <ul role="group">







      <li role="presentation"><a role="treeitem" href="File1.htm">File 1</a></li>







      <li role="presentation"><a role="treeitem" href="File2.htm">File 2</a></li>







      <li role="presentation"><a role="treeitem" href="File3.htm">File 3</a></li>







    </ul>







  </li>







  <li><a role="treeitem" aria-expanded="false" href="Photos.htm"><img height="9" width="9"







    src="img/tree-p.png" alt="+" />Photos</a>







    <ul role="group">







      <li role="presentation"><a role="treeitem" href="Image1.htm">Image 1</a></li>







      <li role="presentation"><a role="treeitem" href="Image2.htm">Image 2</a></li>







      <li role="presentation"><a role="treeitem" href="Image3.htm">Image 3</a></li>







    </ul>







  </li>







  <li><a role="treeitem" aria-expanded="false" href="Music.htm"><img height="9" width="9"







    src="img/tree-p.png" alt="+" />Music</a>







    <ul role="group">







      <li role="presentation"><a role="treeitem" href="Song1.htm">Song 1</a></li>







      <li role="presentation"><a role="treeitem" href="Song2.htm">Song 2</a></li>







      <li role="presentation"><a role="treeitem" href="Song3.htm">Song 3</a></li>







    </ul>







  </li>







</ul>







</div>

Script

The ToggleTree() function cancels the default action for the <a href> and then goes to work finding the list item's child list element. Once that's found, the display of that child list element is toggled, and the list item's image and alt are swapped.

function ToggleTree(evt,src)







{







  HarmonizeEvent(evt);







  evt.preventDefault();







  var node = src.parentNode.getElementsByTagName("UL")[0];







  if (node)







  {







    var img = src.getElementsByTagName("img")[0];







    if ("block" == node.style.display)







    {







      src.setAttribute("aria-expanded", false);







      node.style.display = "none";







      if (img)







      {







        img.src = "p.png";







        img.alt = "+";







      }







    }







    else







    {







      src.setAttribute("aria-expanded", true);







      node.style.display = "block";







      if (img)







      {







        img.src = "m.png";







        img.alt = "-";







      }







    }







  }







}

CSS

The CSS for the tree is fairly simple. Margins, padding and list glyphs are turned off, and child list elements are hidden

div#treeBox { width:15em; font-size:90%; }







ul#tree, ul#tree ul { list-style-type:none; margin:0; padding:0;







  background-color:window; color:windowtext; }







ul#tree a { color:black; text-decoration:none; display:block; display:inline-block;







  height:1.5em; padding:0.1em 1em 0.3em 0.5em; }







ul#tree a:hover { text-decoration:underline; }







ul#tree a:focus { color:highlighttext; background-color:highlight; }







ul#tree a img { border:0; vertical-align:baseline; margin-right:0.5em; }







ul#tree ul { display:none; margin-left:2em; }

Conclusion

In this article, we have discussed how to design accessible web applications for browsers with and without ARIA.  We have also discussed ways to add ARIA to enhance the experience for users who have it, while still providing a good accessibility experience for those who do not. While legacy browsers may require more creativity and resources to improve your users’ accessible experience, it is still possible to provide an accessible experience in an environment with older technology. 

Rate: