This page is part of a suite of related documents. Please refer to the “How to Use These Documents” section for more information.
Many Web sites have already adopted the Web Content Accessibility Guidelines (hereinafter referred to as [WCAG]). WCAG explains how to make Web content accessible to people with disabilities. In many cases compliance with WCAG is mandatory. The Mobile Web Best Practices 1.0 (hereinafter [MWBP]) document specifies Best Practices for delivering Web content to mobile devices. The principal objective is to improve the user experience of the Web when accessed from such devices.
Increasingly, web content is designed to comply with one of these sets of guidelines or best practices. However, misunderstanding of their requirements and the assumptions about the user and device characteristics on which they are based, leads to less than optimal implementation. This document is intended to serve as an added justification or argument for aiming for compliance with either of the recommendations. The benefits include:
It may be useful for building the business case for adopting either [WCAG] or [MWBP] in a web site that already complies with one, or for adopting both together. For accessibility, the Web Accessibility Initiative provides a guidance document Developing a Web Accessibility Business Case for Your Organization.
Accessibility specialists are not generally concerned with the mobile context. Likewise Mobile Web specialists tend not to be concerned with accessibility for persons with disabilities. However they do have common requriements and design principles.
Unlike the Web Content Accessibility Guidelines, the Mobile Web Best Practices are not prioritised. [MWBP] relate to checkpoints of all the WCAG 1.0 priorities (1, 2 and 3).
While there appear to be many similarities between many of the WCAG provisions and those of the Mobile Web Best Practices, in reality there are many subtle differences. A simple table would be misleading and lead to duplication of work in some aspects and and inadequate implementations in others. Also the relationships are not symmentrical (SC x relates to BP y, but it does not follow therefore that BP y relates to SC x).
Readers familiar with accessibility and WCAG can not be expected to be aware of the mobile web, mobile devices, infrastructure and the MWBPs. Similarly, Mobile Web specialists can not be expected to have a thorough knowledge of the needs of users with disabilities and assistive technology. More information and guidance is needed.
While disabled users have involuntary disability, we can think of all mobile users as having a kind of voluntary “disability” due to their choice of technology (the mobile context) that parallels innate disability.
Users of mobile devices experience limitations. Users with disabilities, even with full-featured desktop devices, may experience certain physical, sensorial or cognitive limitations that are not related / relevant to those of the general mobile user.
Users of mobile devices experience limitations imposed by the features of devices and user agents and the environmental context in which they often access the Web. Note that mobile devices vary widely, not all the problems described are present on all models. the table below is not exhaustive, but has been selected to demonstrate the parallels between the two contexts of use.
The table below shows that in the example aspects, although the cause may be different in each context, the result is generally similar in both. Implementing accessibility guidelines will in many ways improve the experience for users in the mobile context. Similarly, implementing best practices for the mobile context will improve the experience for users with a range of disabilities.
|Content Feature||Disabled user characteristics (any context)||General user and device characteristics (mobile context)||Result|
|Interaction and navigation requires mouse||User with a motor disability may not be able to use a mouse||Device has no mouse, only alphanumeric keypad or rocker switch||User unable to navigate all content, or wastes time moving through numerous links.|
|Information conveyed using color (for example, “required fields shown in red”) with no redundancy.||Blind or colorblind user perceives color incorrectly or not at all.||Screen has reduced color palette (DDC). Device is used in poor lighting (outdoors, near flashing lights), so colors are not clearly perceived.||User perceives color incorrectly or not at all, and so misunderstands information, makes mistakes.|
|Large page or large images||User with restricted field of vision or using screen maginfier.||Mobile device has small screen (viewport).||User only sees small areas at a time (keyhole view), unable to relate different areas of page; becomes disoriented or has to scroll excessively.|
|Multimedia with no captions||Deaf or hard of hearing user can't hear.||Mobile users often in public places (trains, hotel lobbies) turn off sound; often in noisy places (streets, nightclubs) can't hear.||User misses soundtrack.|
|Audio-only prompts (beeps, buzzes) for important information (warnings, errors)||Deaf or hard of hearing user can't operate content.||In noisy place (street, nightclub) can't hear.||Can't operate or interact correctly with content, misses warnings, makes mistakes.|
|Free-text entry (for example, alphbetical characters allowed in numeric fields)||User with motor disability (partial paralisis, hand tremor, lack of sensitivity, coordination).||Device has small keypad, or is held in unsteady hand.||User enters text incorrectly, makes mistakes.|
|Embedded non-text objects (images, sound, video) with no text alternative.||Disadvantaged user with slow connection prefers not to wait for download.||User with low bandwidth or who declines to run up connection charges. Already small images redimensioned even smaller in adaptation, become meaningless.||Information loss due to lack of alterantive. User can't perceive infromation.|
|Important information in non-text content (images, multimedia, CSS effects)||Blind or low-vision can't perceive content.||User billed for download volume, turns off images to save costs. Device has no CSS support.||User misses important information.|
|Long words, long and complex sentences, jargon||User with cognitive disability.||Text is displayed in small font, and user is often distracted by ambient conditions (background noise, conversations, moving objects in field of vision).||User finds content difficult to understand, becomes confused.|
|Content formatted using tables or CSS, and reading order not correct whern linearised (for example when CSS or tables not rendered)||Non-visual (screen reader) user reads content in document tree order.||Meaning of content altered by reformatting or restructuring in adaptation process.||Content is garbled, user becomes confused.|
|Scripting required to operate or generate content.||User's assistive technology or browser doesn't support scripting.||Scripting turned off or not supported.||Information loss. Content inoperable.|
|Special plugin required||Plugin turned off, not installed, not compatible with assistive technology. Plugin not operable with preferred input device.||Plugin turned off or not installed; not compatible with input device (for example, requires mouse).||User can not perceive content or can not operate interface.|
|Invalid or unsupported markup.||User has “old” or unusual browser to acommodate special needs.||Mobile device has embedded browser not catered for by content provider. Content passes through adaptation process(es).||Browser or adaptation system chokes on markup; rejects or garbles it.|
|Content spawns new windows without warning user.||User with low vision, restricted field of vision, or blindness doesn't realize active window is new.||Single window interface. Multiple stacked windows on small screen hide each other.||User becomes disoriented among widows; back button doesn't work. User closes window, not realising it is last in stack, closing browser instance.|
|Information conveyed only using CSS (visual formatting)||Blind user doesn't perceive visual formatting effects.||Often no CSS support by mobile browser.||Information lost or altered.|
|No tactile feedback||Device put away||[Bruno please clarify]|
|Content blinks, moves, scrolls or auto-updates||People with reading disabilities, cognitive limitations, and learning disabilities do not have sufficient time to read or comprehend information.||Reduced size of mobile viewport or poor ambient lighting make it difficult to see content.||Difficulty reading and comprehending content.|
|Long page title, with generic information first and differentiating information last||Page titles are used to generate a list of links in site map, screen reader user, person with reading disability or reduced field of vision can't scan the page and reads repetitive information first.||Page title truncated to fit narrow viewport of mobile device.||Difficulty reading list, misses important information at end of title.|
|Focus (tab) order does not match logical document content sequence||User with (for example) motor disability uses keyboard for navigation not mouse.||Pointing device not present or inadequate.||User is unable to navigate content in logical sequence, become disoriented.|
|Link text not descriptive||User can not determine purpose of link||User can not determine purpose of link||Mobile user incurs delay and cost, due to network charges and device limitations. User with disability becomes confused or disorientated; arrives at inaccessible content. [@@ Note these are different]|
Both the Mobile Web Best Practices and WCAG provide information about the possible barriers to users, and advice about how to avoid them. Compliance does not guarantee usability or accessibility. Barriers may arise other than those described and content providers should avoid them by performing user testing. Other solutions than those described may be found to the barriers. User testing should always include a full range of users, including those with different disabilities.