Introduction
editIn general Accessibility is the degree to which a product, device, service, environment or in our case a website is available to as many people as possible. Accessibility can be viewed as the "ability to access" and benefit from some system or entity. The concept often focuses on people with disabilities or special needs and their right of access, enabling the use of assistive technoligy.
Existing online community platforms often do not offer the best possible accessibility/usability experience for elderly users or new users in general: user interfaces are not always as clear and intuitive as they should be, functionalities are sometimes hard to understand at first sight, assistive functionalities for people with disabilities may be absent, while help pages may be hard to find or badly structured.
There have been a few major movements to coordinate a set of guidelines for accessibility for the web. The first and most well known is The Web Accessibility Initiative (WAI), which is part of the World Wide Web Consortium (W3C). This organization developed the Web Content Accessibility Guidelines (WCAG) 1.0 and 2.0 which explain how to make Web content accessible to everyone, including people with disabilities. Web "content" generally refers to the information in a Web page or Web application, including text, images, forms, and sounds. (More specific definitions are available in the WCAG documents.)
The WCAG is separated into 3 levels of compliance, A, AA and AAA. Each level requires a stricter set of conformance guidelines, such as different versions of HTML (Transitional vs Strict) and other techniques that need to be incorporated into your code before accomplishing validation. Online tools allow users to submit their website and automatically run it through the WCAG guidelines and produce a report, stating whether or not they conform to each level of compliance. Adobe Dreamweaver also offers plugins which allow web developers to test these guidelines on their work from within the program.
Recommendations
editExamples of website features that can help to make it accessible include the following:
- At least WAI-AA (preferably AAA) compliance with the WAI's WCAG
- Semantic Web markup
- (X)HTML Validation from the W3C for the pages content
- CSS Validation from the W3C for the pages layout
- Compliance with all guidelines from Section 508 of the US Rehabilitation Act
- A high contrast version of the site for individuals with low vision, and a low contrast (yellow or blue) version of the site for individuals with dyslexia
- Alternative media for any multimedia used on the site (video, flash, audio, etc.)
- Simple and consistent navigation
- Device Independent
While WCAG provides much technical information for use by web designers, coders and editors, BS 8878:2010 Web accessibility - Code of Practice has been introduced, initially in the UK, to help site owners and product managers to understand the importance of accessibility. It includes advice on the business case behind accessibility, and how organisations might usefully update their policies and production processes to embed accessibility in their business-as-usual.
Another useful idea is for websites to include a web accessibility statement on the site. Initially introduced in PAS 78, the best practice for web accessibility statements has been updated in BS 8878 to emphasise the inclusion of: information on how disabled and elderly people could get a better experience of using the website by using assistive technologies or accessibility settings of browsers and operating systems (linking to BBC My Web My Way can be useful here); information on what accessibility features the site's creators have included, and if there are any user needs which the site doesn't currently support (for example, descriptive video to allow blind people to access the information in videos more easily); and contact details for disabled people to be able to use to let the site creators know if they have any problems in using the site. While validations against WCAG, and other accessibility badges can also be included, they should be put lower down the statement, as most disabled people still do not understand these technical terms.
Theoretical Information
editAccessibility in the Context of TAO
In the framework of the TAO project a broad concept of accessibility was applied: Usability and accessibility improvements from a technical point of view have been developed for the CMS that the Wikimedia Communities and the Seniorweb CH Community are running – MediaWiki and Drupal. The assessment of the platform of the German Wikipedia (de.wikipedia.org) and recommendations for improvement are the central issue of this sub-project. The tests have been carried out by a group of blind and multiple-handicapped individuals according to the WCAG 2.0 guidelines of the W3C consortium.
During the test period, test tools such as WAVE, Web Developer, CCS2.0 (a color contrast analyzer), script code analysis and end user tests have been applied. For many drawbacks found, recommendations are given for authors and authoring tools.
The most important accessibility recommendations for de.wikipedia.org are:
- Accessible CAPTCHAs, which provide alternatives to visual verification (e.g. audio CAPTCHAs)
- Better semantic structuring through structural headings, WAI-ARIA landmarks and appropriate usage of HTML 5
- Linked Images, which must inform the reader about its contents, and the fact that they link to the media file page
- Improved Keyboard-Operability, which allows for easier navigation through a web site
- Correct markup of data tables, which facilitates orientation
In order to establish an ongoing improvement process, an “Accessibility Tracking” Group Page (https://www.mediawiki.org/wiki/Groups/Proposals/Accessibility_Tracking) has been developed and brought to life within the Wikipedia resp. Mediawiki ecosystem. he «Accessibility Tracking» group welcomes everyone to support Wikimedia in bringing forward its accessibility. Members are advised to convince decision-makers/programmers in Wikimedia (the core MediaWiki software as well as the different chapters) to solve known accessibility issues and to promote considering accessibilty when writing articles in the community. The core element of the group page is an interactive table summarizing the results of the test report. Every single issue is represented with its WCAG 2.0 test criterion number, a traffic-light-like symbol indicating whether problems could be resolved or by whom they best get tackled, a short description of the problem and a column for additional information. The original test report is directly linked. The group page will be open for editing to everybody. Issues can independently be resolved and traffic lights can be changed accordingly. We expect new accessibility issues to be added and we hope that also issues from other than the German chapter will be entered. Besides the tracking system, an accessibility checklist for authors and publishers has been developed and integrated, as well as an assistance tool (CAC – Content Accessibility Checker) which analyzes accessibility issues on MediaWiki based websites. The CAC tool is also published on GitHub under the Creative Commons Licence (CC BY 3.0 CH): https://github.com/Access4all/ContentAccessibilityChecker
References
edithttp://www.w3.org/WAI/ Web Accessibility Initiative (WAI)
http://www.w3.org/TR/WCAG20/ Web Content Accessibility Guidelines
https://en.wikipedia.org/wiki/Accessibility
https://www.mediawiki.org/wiki/Groups/Proposals/Accessibility_Tracking
Links to Other Handbook Chapters
editChapter on "Target Groups" (gives an overview of older adults as a target group for online communities)