Mobility is an important aspect of accessibility. Indeed, to make the Web content accessible to all means whatever the hardware and kind of connection, it must have access to the same content via a mobile device with a computer. Moreover, users of mobile devices and people with disabilities have similar barriers when interacting with Web content. Therefore to move from a traditional website (designed to run on a computer) toward a version accessible via a mobile device requires some methodology:
1. Appropriation of concepts:
- Understand the basis of migration to mobile:
What is Web Accessibility and which are principal stakeholders? (Authoring tools, User agents, User…)
How people with disabilities use the Web?
Which are essential components to switch to mobile?
2. Listens and research needs:
- Do market analysis and statistics of your website to quantify the mobile traffic to determine the project’s feasibility (and market trend), to know what kind of people will use your website and to have a rough idea of the type and amount of accessibility barriers on your website (Preliminary Review).
- Listen to your customer needs to determine what will be contents and features to put on the website. It is the basis for user-centered approach. Mobile users are more in looking for information than in complex tasks: to find a restaurant, and not to order his meal online.
3. Analysis and specification:
- Set the target for accessibility:
For example, an organization sets its target to meet WCAG 1.0 Priority 1 and Priority 2 checkpoints (also known as Level Double-A conformance).
The motivations and pressures for the retrofitting project will likely influence the target. Developing an accessibility policy is a good way to clarify and communicate the aim.
- Evaluate to identify the issues of accessibility and mobility:
The goal of evaluating before retrofitting is to define the accessibility and mobility barriers on your site and gather information to plan an efficient retrofitting project.
Prioritizing the repairs by barriers and area:
Barriers: A more effective approach in most cases is to do all of the high impact and easy repairs while you are working on a page, template, style sheet, etc. Then address harder problems later.
Area: Certain pages may have higher priority like the home page.
4. Upgrade to standards :
- Develop a flexible technology able to evolve complying with the W3C standards:
Designed the website to meet Web standards such as XHTML and CSS, and meets the Web Content Accessibility Guidelines (WCAG) and the Mobile Web Best Practices (MWBP).
Moreover, it will be possible that you had to create more than one versions of your mobile site to meet the peculiarities of some phones:
W3C standards have designed to make access Web content, but to improve the appearance of the application you may need to design a new interface.
After you have repaired the major accessibility and mobility barriers on your website, there are several things you can do to help avoid creating new barriers and to continue improving the accessibility and mobility of your site:
Ensure that you have an effective accessibility policy in place that specifies that your website meet or exceed legal requirements.
5. Prototype and design:
- Create a simple interface which allows you to easily back to the homepage, to go from one page to another and to include a breadcrumb to help the client to move through pages:
Navigation on a computer web browser on is different with navigation on a mobile web browser e.g. mobile phone users will have a hard time if a Web site’s navigation requires the use of a mouse because they typically only have an alphanumeric keypad.
6. Evaluations and tests:
- Test models early in the process and on various devices:
Check the compatibility and the portability between different mobile devices.
- Evaluate the website with Validators provided by W3C or other organizations to check standards like CSS, XHTML, etc. The vast majority of the guidelines points should be performed by human.
- Always keep in mind that the bandwidth is slower and more costly to the user:
Avoid Time-based Media, picture decoration, etc. Always provides text-alternatives.
- Do not force the use of mobile site, visitors may wish to see the full version of the site from the mobile version. It’s possible to put a link at the bottom to access the full site.
As navigation is more complicated on a mobile device (mainly due to the keyboard and the screen size), use of widgets is likely the future for the Web mobile. In this context, a widget is a downloadable, interactive software object that provides a single service such as a map, a news feed etc. So the widget is lighter, and it’s well designed for the mobile device.
In future, mobility is a great opportunity for user’s implication. Nowadays most of mobile devices embed a host of devices like camera, sensors, etc. We can imagine that users take photos and they are automatically sent on the application via a widget. However, to allow such applications to spread is to set standards for APIs that use the components of these devices to facilitate the widgets portability.