Resources

The Value of Manual Accessibility Evaluation

Tim Shelton
AccessibleTech, Inc.

With the enactment of Section 508 of the Rehabilitation Act, which requires that all government and government-employee-used software be accessible to all potential users, including those with special needs, there have been many proposed methodologies and tools for evaluating compliance. Users with special needs include, but are not limited to, the vision-impaired, the hearing-impaired, the elderly, and those with limited cognitive and motor capabilities. Many devices and software suites exist to aid these users in interacting with and enjoying websites and software. However, these assistive technologies cannot make software accessible on their own; software designers and developers must do their part to help make software available to all users. There is much debate centering on the use of automated tools versus manual assessment for software accessibility evaluation. Automated tools can prove helpful in the process, however their use has its limits; manual efforts are still always required in removing all barriers to accessibility.

Automated tools for aiding in the accessibility evaluation process exhibit many beneficial functions. They can be used throughout the development process or after the fact, during post-implementation. Due to their nature, automated tools can quickly check through entire pages of code and can perform large quantities of testing scenarios - both much faster than a human would be able to do. This enables them to save time and reduce the workload for developers. However, there is the possibility that some results generated by automated tools will simply be false, often unbeknownst to an untrained evaluator. These tools can incorrectly flag something as complaint, even when it does not truly make the system accessible, or incompliant. An experienced accessibility analyst can effectively sort through the results given by an automated tool and use those results that are true barriers to their benefit.

The way most automated tools work is by identifying syntactic errors in code and areas for further, manual evaluation. They can point out missing content that would help make a page accessible. For example, automated tools can effortlessly check to see if an image tag includes an alternative description (alt text). These tools also suggest places where it is possible or even likely that a change should be made, but they cannot tell for sure. In these cases, a human would have to judge the code to determine if it complies. Going back to the alt text example, automated tools can identify if the code for the description is present and they may even be able to see if the description has not been left blank. But, automated tools cannot look at an image and its alternative description and conclude that the description appropriately describes the image in a clear and concise manner. Human judgment is required in this case.

Manual evaluation is essential for accessibility implementation. Besides human judgment often being a critical component to the process, there are some accessibility barriers that automated tools cannot detect. Only a human can turn on a screen reading tool and assess software from the perspective of a vision-impaired user. When employing a screen reader, human judgment is required to consider characteristics such as ease of navigation (without a mouse) and time it takes to locate desired content. Also, many special needs users opt to disable styles when browsing websites and it is not uncommon for unexpected barriers to then appear, such as with content layout. There is also the chance that unexpected barriers can occur when the system is run on a different platform or browser. In these scenarios, the evaluator must visually assess the system to ensure compliance. Finally, if no manual evaluation is used, the evaluator has little to no real interaction with the system, thus eliminating the chance of them performing impromptu tests that may yield additional, undiscovered barriers.

To conclude, automated tools perform a useful function in the evaluation of software accessibility; experienced analysts can see many advantages with their use. However, because of their limitations, they should not be the sole determinant for whether or not software is compliant and usable. Manual assessment is always required in order to guarantee a fully compliant and functional system.

Mobile Web Accessibility

Tim Shelton
AccessibleTech, Inc.

Introduction

With the ever-growing usage of mobile devices to connect to the Internet, users with special needs, such as the blind community, are finding it difficult to keep up. Most of the major cell phone manufacturers and service providers have made some effort towards accessibility, however too often their offerings fall short of total access to the disabled community. It is important to remember that not all mobile users are equipped with the latest technology which may better address accessibility. Software developers, such as those who build mobile websites and mobile applications (which commonly utilize network connections to obtain content), should be aware of the current status of accessibility technology on mobile devices in order to ensure equal access to all users.

According to the American Foundation for the Blind, most cell phone carriers offer only a limited selection of devices with built-in accessibility features and have so far made little effort to correct this shortcoming. However, these mobile phones may still require third-party applications to enable more-comprehensive access to people with special needs [1]. In addition, some mobile phones that do not come with assistive technology out-of-the-box allow for third-party applications to be installed to help gain access to those with special needs. Fortunately, with the growing popularity of smart phones and app stores, these third-party applications have become easier to obtain.

Currently there is no formal set of guidelines specific to making content accessible on mobile devices. The World Wide Web Consortium (W3C) suggests that developers consider two related sets of guidelines when striving for mobile content accessibility: Web Content Accessibility Guidelines (WCAG) and Mobile Web Best Practices. These specifications cover some of the same issues, but they also offer ways to address barriers unique to each context.

The format of this paper is as follows. First, the availability and capabilities of assistive technology on mobile devices is discussed. Following this, a comparison is made between mobile web access and the accessibility needs of the disabled community. Finally, design considerations specific to mobile web accessibility are outlined.

Assitive Technology on Mobile Devices

Most of the built-in assistive tools on mobile devices are similar to those used on computers, however their capabilities are often lacking or hampered by the nature of mobile devices. Text-to-speech, or screen readers, are available on some devices and can be obtained via third-party software [2]. The downside to mobile screen readers is that they do not always work with all applications or functions of mobile devices and therefore still allow barriers to access to exist [1]. Screen magnifiers, common for those with impaired vision, are also sometimes available out-of-the-box and can be attained from a third-party developer [2]. A problem, though, can arise with the use of a screen magnifier on a mobile device: because the screen is small to begin with, there is the potential for users to completely lose page-location context. The magnifier on a mobile device will likely take up the entire screen, whereas on a computer the magnifier can zoom in on only a portion of the screen while leaving the rest still visible to maintain context-awareness. A good way to address this is to offer buttons at the top of a mobile web page which can increase text size. Another concern stemming from mobile device screens is their quality - some do not offer enough adjustability for brightness and contrast, thus barring some users from access [1]. To prevent this, mobile applications and websites should strive for high contrast (possibly greater than the level commonly required for web accessibility) between the foreground and background.

Also, many mobile phones come equipped with voice control capabilities which can prove beneficial to those with vision or motor difficulties, but this often only works for a limited selection of tasks, such as placing a call, and thus does not allow for full access to the device [1]. Discovering a mobile phone’s battery level or signal strength is something often taken for granted by most users. But for the blind community, determining this information and notifications such as those for missed calls and new voice mails can be a challenge. Fortunately, there are some phones that offer audio alerts and announcements of this information, but the widespread adoption of it has yet to come [1]. In addition, audio feedback of button presses where the device reads the name of each key that is pushed as it is pushed (i.e. “voice echo”) is an important feature that is still not largely available on mobile phones [1]. Nokia has gone a step further to aid in accessibility by increasing the buffer memory on its mobile devices to allow users more time to create inputs before the phone cancels the operation [2]. Users with cognitive disabilities may find this increased time allowance beneficial when using mobile phones. And, websites and applications that place time restrictions on input should consider the increased difficulty, for all users, of typing on a mobile device and allow a means for extending the allotted time frame.

Mobile Web and Special Needs Users Comparison

Many similarities exist between website use via mobile devices and accessibility for users with special needs. To begin, mobile devices have no traditional mouse to handle interaction. Similarly, blind users and those with impaired vision and motor functionality often avoid using a mouse and instead turn to keyboard interactions (tabbing through content) while listening to a screen reader [3]. Mobile device interactions for these types of users (and some non-disabled users) often involve navigating through content with the tab key or one with similar forward progression functionality [3]. Therefore, it is important to keep this navigational technique in mind when developing content to be viewed on mobile devices. Design considerations include using header tags with descriptive headers for each section and sub-section, keeping page sizes short and content relevant, and assuring pages have correct tab or focus order.

Mobile devices are commonly used in environments where the user should not have audio turned on (e.g. in a public location) or where background noise is sufficient enough to drown out the device [4]. Similarly, the deaf community cannot rely on audio content and alerts. Thus, content developers should employ appropriate text [4] or haptic (e.g. vibration) alternatives to any auditory information.

In addition, text entry can be a challenge for all mobile users due to the limitations of mobile keypads. For example, many mobile phones do not have full qwerty keyboards or, if they do, the buttons are generally very small or virtual (i.e. on a touch screen). Users with impaired motor functionality face an even greater challenge when attempting to type text into a mobile device. So, to address this, content developers should consider employing default values for entry fields and other ways to minimize keystrokes, such as keeping URL lengths to a minimal size [4].

CSS support and plug-in installation are not always available for mobile device users. And often, users with special needs disable CSS or opt to use their own customized style sheets, or assistive technologies are discovered to be incompatible with plug-ins. Therefore, mobile developers ought to create websites that do not rely on style sheets to make them properly viewable and should not require that users install a plug-in [4].

Finally, pop-up and auto-refreshing pages should be avoided for mobile websites. Pop-up windows can appear without warning and block or take the focus away from the user’s current page and thus potentially confuse blind users employing a screen reader or those with cognitive impairments [4]. Automatically updating or refreshing pages can not only confuse some users, but they can take away content before a screen reader or a user with a cognitive impairment has the opportunity to read and comprehend it [4]. Also, specific to the mobile context, pop-up and auto-refreshing windows can create additional and often undesired charges for users.

Mobile Web Design Considerations

The W3C recommends that mobile content developers follow two sets of guidelines to ensure full accessibility: the WCAG and Mobile Web Best Practices. By doing this, developers will address both accessibility on mobile devices and for users with special needs. Adhering to the accessibility approach for non-mobile content (section 508 and WCAG) will cover many of the issues that may arise on mobile devices. There are, however, some accessibility concerns that are specific to or more prominent when using mobile devices. Moving text, for example, should be avoided when designing mobile content [5]. Also, screen magnification tools may not be available to mobile users, so content developers should allow for an easy way to increase text size [5], such as through a button at the top of each page. Text is easier to read when in mixed-case format, so content in all capital letters ought to be avoided. Finally, it is suggested that Arabic numerals be used in lieu of Roman numerals [5].

- Section 508 and WCAG

Section 508, part of the US Rehabilitation Act, outlines accessibility requirements for government IT systems and is recommended for use for all software and website developers. See AccessibleTech’s Section 508 Explained e-book for an in-depth look at section 508’s requirements. The Web Content Accessibility Guidelines 2.0, which include many suggestions similar to section 508, offers design considerations to make non-mobile web content accessible to all users. Both section 508 and WCAG should be implemented when designing content for mobile web.

- Mobile Web Best Practices

The W3C has established a series of best practices for mobile web development. These best practices are not specific to accessibility for users with special needs, however adhering to them can greatly aid in accessibility to users of the disabled community. An important aspect to take into consideration is the screen size. Because mobile devices have limited screen space, developers should strive for a minimalistic approach. This includes creating small, concise navigation regions, keeping page content and length to a minimum, and using small images when images are essential [6]. When using style sheets, it is suggested that they, as well as any markup, be kept short in length [6]. Other considerations relating to navigation include clearly labeling the destination of hyperlinks, especially if they are external files such as PDFs, and reducing the number of steps a user must take in order to reach their desired content [6]. Also, tables, including those used for formatting purposes, should not be employed because they can force horizontal scrolling which can be frustrating and confusing. And beyond that, many mobile devices do not allow the use of tables [6]. Instead, creating a page hierarchy through section and sub-section headers is suggested. Further, many mobile devices do not allow frames and image maps, so their use is not recommended [6]. See W3C’s Mobile Web Best Practices page for full details.

Conclusion

Developing content for mobile devices can prove more challenging than doing so for non-mobile devices. The assistive technology available for use with mobile technology is less widely-available and still lacking in some areas. To ensure their content is accessible to all users, it is critical that mobile software and web developers take this into consideration and adhere to section 508 and other web accessibility guidelines as well as the recommendations for designing mobile websites.

Works Cited

1. "Cell Phone Accessibility Overview." American Foundation for the Blind. Web. 20 June 2011. .

2. "Making Mobile Devices Accessible For All." Nokia Accessibility. Nokia. Web. 20 June 2011. .

3. "Web Content Accessibility and Mobile Web: Making a Web Site Accessible Both for People with Disabilities and for Mobile Devices." World Wide Web Consortium (W3C). Ed. Justin Thorp and Shawn L. Henry. 14 Oct. 2008. Web. 20 June 2011. .

4. "Shared Web Experiences: Barriers Common to Mobile Device Users and People with Disabilities." World Wide Web Consortium (W3C). Ed. Yeliz Yesilada, Alan Chuter, and Shawn L. Henry. 1 June 2009. Web. 20 June 2011. .

5. "Mobile Phones." Tiresias. Web. 20 June 2011. .

6. "Mobile Web Best Practices 1.0." World Wide Web Consortium (W3C). Ed. Jo Rabin and Charles McCathieNevile. 29 July 2008. Web. 20 June 2011. .