Accessibility is a general term used to describe the degree to which a product (e.g., device, service, environment) is accessible by as many people as possible, and the ventures to produce accessible products and services. Accessibility is often used to focus on people with disabilities and their right of access to entities, often through use of assistive technology.
The detailed Mission Plan for the Special Needs Special Interest Group (SIG) of the Society for Technical Communication (STC) has an objective to extend the availability of online technical communication resources and a strategy for achieving that objective. Specifically, Strategy 1.5, reads as follows: Encourage Special Needs SIG members to research and report on the use of telecommuting in the field of technical communication and study the viability of telecommunication as a means of increasing the employability of practitioners with special needs.
Most developers don't think about individuals who are deaf when they think of Web accessibility. For too many developers, Web accessibility consists of adhering to a few guidelines that ensure accessibility to screen readers for the blind. On one level, this is understandable. People who are blind will have the most trouble, since the Web is a visual medium...or is it?
For this study, we recruited low-vision users with a variety of vision problems who need software to magnify computer text. Although we did not systematically recruit for specific vision problems, the fact that our users had different needs gave us one of the most critical insights in this study: The needs of low-vision users are too diverse for simple solutions to Web accessibility and usability. We show a few ways in which today’s Web sites are missing the needs of all low-vision users and provide guidelines for fixing those problems. However, the diversity of vision needs and the resulting adaptations that low-vision users require mean that there are no simple solutions to making Web sites work for everyone. In this article, therefore, you will not find many simple guidelines. Instead, we raise a critical issue and suggest a 'vision of the future' solution.
When I hold workshops for people who want to learn more about web standards and accessibility, I often notice that the attendants really have tried to improve their accessibility knowledge. But they get overwhelmed when they go to the official documentation from the W3C and try to understand it.
HERA is a tool to check the accessibility of Web pages accoridng to the specification Web Content Accessibility Guidelines (WCAG 1.0). HERA performs a preliminary set of tests on the page and identifies any automatically detectable errors or checkpoints met, and which checkpoints need further manual verification.
It’s no coincidence that search engines love highly accessible websites; in fact, by designing for accessibility, you’re already using effective search-engine optimization techniques. Andy Hagans explains yet another reason to pay attention to accessibility.
Anyone with good graphic-design skills can use Web standards to produce attractive Web sites that function adequately for nearly all viewers and very well for most viewers – including people with disabilities. This article will explore a few details concerning the interplay of accessibility and Web design.
When Apple released Safari on to the unsuspecting world in 2003, it caught a lot of people off guard. The ripples are still being felt - Mozilla's source code was rejected in favour of the smaller code base of KHTML, and more recently Opera has suggested that it may no longer make a version of its browser for the Macintosh platform. And then, of course, there's the whole issue of how web developers can keep up with yet another browser foisted upon them - does it support agreed web standards? Or does it break standards-compliant sites in horrible new inventive ways?
This document provides an introduction to use of the Web by people with disabilities. It illustrates some of their requirements when using Web sites and Web-based applications, and provides supporting information for the guidelines and technical work of the World Wide Web Consortium's (W3C) Web Accessibility Initiative (WAI).
This tutorial aims to help you add voice interactivity to your site, with minimal code changes and maximal browser compatibility. Along the way, examples will be provided, and at the end, you will be able to test a fully working, real World, voice-enabled site. This tutorial describes the use of a reusable VoiceXML form. Because the voice capability is included in the browser, you do not need to write your own speech recognition engine or speech synthesizer. This is a great advantage to you and to your Web application users.
Surely there can't be a skill to writing ALT text for images? You just pop a description in there and you're good to go, right? Well, kind of. Sure, it's not rocket science, but there are a few guidelines you need to follow.
Web accessibility is a label which few web designers, let alone their clients, fully understand. Many companies are unintentionally misleading customers by claiming to design accessible websites due to the lack of technical skills and understanding of the accessibility guidelines (WCAG 2.0).
When a client requests that I duplicate functionality that should be (and is) handled by web browsers, I always try to avoid doing it by explaining why I believe it is better to leave such functionality to the browser. Most of the time I succed, but occasionally I don’t.
First, if you don't produce forms for federal government, it is wasted time, but there is information available. Adobe has the accessibility section on its Web site with useful documentation. There are other Web sites about accessibility in general on all the federal government sites, and finally, there are further links from there. Also, if you are providing forms for a federal government agency, you should get in touch with their 'Section 508 representative,' who will give you guidelines for that agency's way to implement it.
So you have a blog, and you're worried that it might not be accessible to people with disabilities? Don't worry! A few simple changes can increase your blog's potential readership.
If you choose to make standards-compliant websites, inevitably you will have to follow the guidelines. It's foreseeable that you could be legally required to follow WCAG 2.0. You could opt into following the guidelines or they could be foisted upon you. You thus have an enlightened self-interest in ensuring the new guidelines actually make sense. Moreover, we simply need more contributors.
You want to build accessible sites, but your clients don't see the need. How can you convince them to fork over the cash it'll take to ensure their site's accessible by all Web users? Trenton has the answers...
On August 18, 2005 new Disability Standards for Education came into effect in Australia. Questions have been raised about how they may impact on the way universities publish resources on the web. In this article, I provide an overview of the new Standards, their general impact, and conclude that if organisations are already following the advice of the Human Rights and Equal Opportunity Commission (on how to comply with the Disability Discrimination Act 1992 in relation to the web), the introduction of the Standards should make no appreciable difference.
Probably the most worrying thing about the HTML Working Group is the lack of respect for differing opinions that some working group members have. The apparent disinterest in accessibility is another troublesome factor.
As I wrote in Help screen reader users by giving data tables a summary, the summary attribute on the table element can be used to provide information that helps non-sighted users understand data tables. The current draft of HTML 5 requires that validators display a warning if they encounter a summary attribute, since it is now an 'obsolete but conforming feature.'