Accessibility and Usability
Accessibility
What is it?
As stated by W3C:
Web accessibility means that people with disabilities can use the Web. More specifically, Web accessibility means that people with disabilities can perceive, understand, navigate, and interact with the Web, and that they can contribute to the Web. Web accessibility also benefits others, including older people with changing abilities due to aging.For complete details, refer to the full W3C article giving an introduction to accessibility.
For NZ government agency web sites, accessibility extends to more than disabilities. It includes consideration of users who may not enjoy the benefits of a modern day user experience, the reasons being factors such as
- Having older client technology including older computers, operating systems and/or browsers.
- Slower and/or restricted internet access. This can occur for users in rural and/or remote parts of the country and/or those with dial up connections.
- Having certain technologies disabled at some point in the users’ internet connection which is beyond the user’s control. For example, if the user accesses via a workplace/internet kiosk which bars scripting. Applications that rely on scripting will not be accessible to such users in such situations.
Designing accessible navigation
Traffic lights are a tool of navigation that everyone has to use in their everyday life. For pedestrians with sight, there are lights. For pedestrians that can hear but not see, there are sounds. For pedestrians that can neither see nor hear, there is a vibrating pin below the button you press when you want to cross. In other words, traffic lights adapt to the needs of a variety of users.
The web was designed to be adaptable too, but design for the web often overlooks this.
Text is the most efficient way of creating navigation labels. As text, a word like Contacts takes 8 bytes. As an image, it will be at least 50 times as large, and the text will have to be provided in any case, as alt text.
Text is accessible. Text can be read or spoken. Properly designed, users with poor vision or motor control can made it bigger or change its colour. You can’t do that with an image. Underlined text, usually coloured blue, is universally recognised by visual users as a link.
Navigation blocks are usually lists of links. It is important that the list is properly punctuated. The WAI Accessibility Guidelines recommend putting a printing character like a “ | ” between adjacent links. This can help users of older screen readers, as well as people with motor impairments. A tab index for link lists can also help people who have difficulty controlling a mouse to tab through to the link they want in a predictable order.
Scripted menus can obscure the destination of a link, be ignored by users (that can’t or don’t want to run scripts) or blocked by firewalls, be difficult to use if you have trouble controlling a mouse, add considerably to the size of a document and lead occasionally to fatal errors in older browsers. Careful assessment of the needs of users and the benefits of scripting should be made before adopting this approach. Adding accessibility features to global templates is not onerous.
One kind of image-based link aids accessibility for non-visual users and should be added to the beginning of every web document. A single-pixel ‘invisible’ image that links to an anchor at the start of the main content of the page. Visual users don’t see it, but non-visual users hear it at the start of the page so they can avoid hearing the global navigation block yet again.
Borrowed from W3C: http://www.w3.org/WAI/intro/components-desc#guide
Further references for accessibility: http://www.washington.edu/doit/Brochures/Technology/universal.design.html
Making sites accessible with scripting: http://www.doit.wisc.edu/accessibility/Scripting.doc"
Accessibility and emerging technologies
Rich Internet Applications
This is a category of web applications, which has features more akin to those of traditional desktop applications that matured from the “client-server” concept. In this concept, the majority of data involved with the application is managed by the application server, whilst the majority of presentation processing is at the client end.
At the time of writing, such applications are credited with being more responsive and providing a richer user experience – for a certain category of users however.
As borrowed from W3C:
These rich Internet applications make heavy use of scripting, and developers often improvise hybrids of existing technologies, including AJAX, DHTML, JavaScript, Flex and SVG. These applications do not always provide the semantics needed to support these technologies. People with disabilities are therefore at risk of being left out of this new world of information.
These standards and recommendations do not rule out the use of Rich Internet Application technologies, in fact mention of specific technologies in general has been deliberately kept to a minimum. It is the domain of NZ government agencies to determine the technologies they deem appropriate for their web site strategies and developments, as long as the resultant web sites are compliant with the standards and recommendations.
Agencies are encouraged however to share their advice and comments (good and bad) on relevant technologies in the Best Practice sections of the Web Standards and Recommendations.At the current time, agencies can submit their advice and comments to web.guidelines@ssc.govt.nz.
For further details on Rich Internet Applications, refer to Wikipedia
Accessible Rich Internet Applications
The W3C has developed a roadmap for Accessible Rich Internet Applications (WAI-ARIA) to address accessibility issues with Rich Internet Applications. Refer to WAI-ARIA for further details.
Usability
What is it?
Usability is the measurement of how a service/product/system performs to meet its intended purpose(s) for the targeted audience(s).
The International Standards Organisation (ISO) has defined usability to be:
The extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use. (ISO 9241-11)
Users
Users are the target audience(s) that the particular service/product/system is catering for. The users can be grouped by their intended usage, needs, demographics, levels of experience/education and context of use. These can be turned into user profiles or personas to inform the strategy, design and development of the product. User groups may include internal groups such as IT operations, helpdesk, communications and business owners.
Goals and Objectives
These are determined by the business owners or sponsors and by the user groups of the product. These goals will reflect what the sponsor(s) want the product to achieve for them and the user. Each goal needs to be specific enough to inform development, to be aligned with the overall business strategy, measurable, achievable and timely. These goals and objectives need to be reassessed periodically to ensure they are still relevant. These goals and objectives can be turned into usage scenarios.
Effectiveness
A measure of the ability for the target users to be able to achieve their goal(s) for the service/product/system.
Efficiency
A measure of the amount of resources (time and effort) used by the target users to be able to achieve their goal(s) for the service/product/system.
Satisfaction
A measure of the user’s perception of the process of achieving (or not) the specific goal(s) for the service/product/system.
There are many schools of thought on the definition of usability. See the reference list below for more readings on this subject.
Benefits of usability
- Cost reduction – for the development, resources and post development of the product
- A more definitive product is produced
- Working towards the overall e-government 2010 milestone
- Reduces risk of the product failing
- Increased customer satisfaction and positive perception of the product and organisation
- Validate concepts, designs, flows and content early on in the development stage
- Decreased number of post implementation changes and problems
Incorporating usability into development processes
Any development process or methodology can incorporate a few user-centred activities, to make it more user-centred (User Centred Design - UCD).
Usability activities can be implemented at different stages of the development process. Most teams would already have some of these activities as a part of their normal development methodology, but may call them a different name or have a different way of conducting them.
User-centred activities
The following is provided as a summary of the most common activities that occur during the stages of development. Some of these activities can be re-used at different stages of the development. Most of these activities need to be measured against the goals of the product, with samples from the user groups. Refer to the resource list below, for more details on the description, planning, resources, organising, implementing and analysing of these activities.
Planning
Stakeholder meetings, define the purpose of the service/product/system, define user groups and their needs, create personas, determine the user experience, Ethnographic studies, review of similar sites, and incorporate findings into the development strategy.
Analysis and requirements
Focus groups, surveys, brainstorming, task analysis, determine the information needs and architecture, card sorting, walkthroughs, story boarding, user observation, interviews, frontline and helpdesk research, rapid prototyping and Fagan inspection methods.
Design
Low and high fidelity prototyping, usability testing, questionnaires, develop content and information architecture guidelines, expert review.
Evaluating
Contextual testing, think out loud protocol, explorative and scenario usability testing, post testing questionnaires. Comparison testing.
Post development/Continuous improvement
Web log/stats analysis, content and information audits (for accuracy, timeliness and consistency), periodical usability testing, user satisfaction research, user feedback, conducting user journals/diaries, frontline and helpdesk research and analysis, testing new concepts with user focus groups.
Who should be involved in the process?
Business/sponsors
Management, business owners, content owners and providers, helpdesk, frontline staff, backend processing, steering / advisory groups and analysts.
IT
Project Managers, business analysts, testing personal, web mangers, web masters, designers, information architects, developers, e-enablement groups, advisors.
Communications
Web Publishing Team, Communications and Publications Advisors, Public and Media Relations.
External groups
Representative users, community groups and stakeholders, marketing, channel managers, usability experts, vendors, SSC representatives.
