Accessibility Project Lifecycle
“I wish for a world that views disability, mental or physical, not as a hindrance but as unique attributes that can be seen as powerful assets if given the right opportunities”― Oliver Sacks
This article will talk about the accessibility project lifecycle. Designing for Accessibility , Digital Accessibility and Topcoder and Accessibility were covered in previous articles. The reader will understand the project lifecycle phases of the Topcoder website accessibility project. In this article, accessibility factors such as forms, links and page structure are accessed for the Topcoder website.
According to Tim Berners Lee, “The power of the web is in its universality. Access by everyone regardless of disability is an essential aspect.” Many users are unable to access information on the web which is causing a dichotomy. Websites need to be designed with accessibility for people with disabilities in mind. HTML5 is the language used for designing and developing the website. Mobile, PDA, and television browsers on computers access HTML5 content. Web browsers are well known for accessing HTML5 web based content.
Users with impaired eyesight might have issues with content, contrast, color and images on web pages. Jaws, Window-Eye, NVDA, Serotek System Access, Apple VoiceOver, ORCA,BRLTTY, Emacspeak, WebAnywhere, Spoken Web, ChromeVox and ChromeVis are well known screen readers which are used for transforming web page content to speech. Some screen readers use a refreshable braille method for display. These screen readers are based on the piezo effect, in which the crystals expand on a specific voltage levels. Fingers are used by the visually impaired users to read the text.
A project for making a website accessible consists of multiple phases such as planning, analysis, design, development, testing and maintenance. The project phases consist of web site design, outlining of the structure, web page template creation, integration of templates, content addition, and website launch.
Design and user interface conceptualization is an important phase of the accessibility project lifecycle. If accessibility is not considered very early, refactoring at later stages can create project planning problems. Updates and maintenance of the website need to be added at the design phase to avoid problems.
Website design is done using wireframes and the accessibility aspects need to be added in the design. The decisions made to create accessibility need to be shared with designers, developers and testers. Accessibility needs to be integrated during development and the unit testing needs to handle the requirements. The QA team validates the accessibility requirements and ensures the website is performing well with assistive technology and web browsers.
For accessibility projects, metrics and tracking of goals are necessary. Accessibility projects will have short term and long term goals for handling the product features and accessibility requirements. The metrics ensure the accessibility improvements and identify issues with web design, defects and prioritization.
Accessibility is a hard development problem. Expertise is required for handling accessibility requirements in the code. The issues are typically design problems for inaccessible page elements related to WCAG 2.0 guideline violations. Accessibility architects and developers need to design and develop websites based on the guidelines.
Development and testing teams need to have the tools for unit and functional testing. Different browsers have extensions and plugins for testing accessibility requirements. The testing tools are planned very early for website releases. The tools used for testing need to be checked for not providing false positives by the QA team who will validate the requirements using those tools and manual testing.
Accessibility projects have similar testing processes like any other QA project. The testers and developers need to follow the accessibility guidelines and requirements, and have the same tools for checking and maintaining the website for accessibility.
Topcoder Accessibility Project
We previously evaluated the Topcoder home page for content, language, contrast, color and images. Now we look at other aspects from the Topcoder website.
Web Page Design Elements : Forms
Web forms need to avoid improper nesting of form elements and links. Placeholder values to label or explain input should not be used. Accessible usage of time based sessions and timed responses are to be considered for form design. CAPTCHAs need to be accessible both visually and audibly. The checkboxes and radio buttons need to be positioned to the left of the labels. Web page elements with more than one label need to be designed well for appropriate rendering. The error messages need to be highlighted at the beginning of the form after submitting. The form component hierarchy needs to be highlighted in a textual manner.The form field constraints and errors need to be positioned at the corresponding fields and the field labels need to be unique.
The form fields need to be laid out in an intuitive order. The option elements in large lists need to be grouped. The radio button groups need to be properly formed. The rich edit entry fields need to be directly accessible and the design should provide for the fields to have an alternative entry method. The common input fields are to be designed for autocomplete using standard autocomplete values.
The form’s instructive text needs to be placed at the beginning of the form. The visible text label for the control needs to be added in the accessible name of the control. The form should have a consistent implementation of error and alert mechanisms. Valid labels for form fields need to be given, with audio cues provided as alternatives.
The current location needs to be indicated in the web search results. Error prevention for legal commitments, financial transactions, test responses, and data modifications needs to be handled properly. Field sets for groups of form controls should be designed well. The suggestions for error messages need to be indicated when known. Valid, concise, and meaningful alternative text should be provided for image buttons. The visual labels and instructions for user input are to be designed for accessibility as well.
Now we will look at the search Topcoder form shown below:
The html for the search form is shown below. Form submission error messages may not identify empty required fields.
All required form fields may not be indicated as required. Form submission error messages may not provide assistance. Form submission data may not be presented to the user before final acceptance of an irreversible transaction. Form may delete information without allowing for recovery. The html needs to be modified to highlight the required fields. The validations of the form need to handle the error messages.
Web Page Content : Links
The web page links need to have alternative text for image links.The link text should be meaningful for scenarios where it is taken out of context as well as meaningful in the context. The web page links should not directly target the web page images and need to be grouped. Using the same link text should be avoided for different target links.
Now we look at the Topcoder web page and the menu for switching to community and connecting to it.
The html for the links is shown below. Link text may not be meaningful and anchor text may not identify the link destination. The html needs to be redesigned for meaning full link and anchor text.
Web Page : Structure
The web page structure should not use implicit headings. Heading elements need to be avoided if not necessary. Long quotes need to be handled using block quote. Proper spacing should be provided for complex text elements. The web page content needs to be visible for assistive tools such as screen readers and others, but hidden from users that do not use assistive technology.
You need to have the heading level match the heading’s visual level. The headings and labels need to be descriptive and unique, and elements should use relative sizing. The markup documents should have well-formed elements. Title elements should be provided and proper markups should be used to mark emphasized or special text. Shape and location are not the only methods which are used to communicate hierarchy.
You need to have short quotations which are wrapped in q elements. The proper quotation markups need to be used.The reading order of content should be logical and coincide with the focus order of the web page. You need to avoid the use of ASCII layouts. You should not use ASCII art to simulate markup. Page titles need to be informative and context sensitive. Keyboard access should be provided for scrollable content.We will start looking at the Topcoder home page for the structure analysis.
The html for the webpage is shown below for the content box showing “Design & Build High Quality Software with Crowdsourcing”. For prime accessibility, the contents of each h1 element need to be checked to ensure the h1 element is a section header.
HTML needs to be modified by removing the h1 element and replacing it with the appropriate text formatting elements.
In the next part of the series, we will look at other areas in the Topcoder home page such as frames, data tables, charts, graphs, keyboard accessibility, trees and outlines, page tabs, dialogs, calendar controls, animations, dynamic content, authoring tools, layout tables, multimedia, multimedia control playback, navigation, and typography.