Audience: Students
10
mil vi, 1.3 legLLy blind
30%
employed
high
school and college age temp jobs, starting at age 16
-"There
are still stereotypes of blind people," he said. "When employers,
educators, even parents of blind kids have those stereotypes and low
expectations, many are being kept down and out."
-"If
someone's blind, there's a huge stigma to overcome and all kinds of myths and
fears in the employer community," EEOC spokesman David Grinberg said.
"The fact is that in the 21st century workplace people who are blind are just as able to do a job as anyone else - they just need to be given a chance," he said. "They know the deck is stacked against them. They work harder than others, and they end out being more effective workers."
1.Video: Accessible Information Technology in Education: Building a Better Future - This video presents the voices of students with disabilities and experts in accessible IT as they discuss the importance of ensuring that information technology is accessible in educational settings.
2.Video:
Surfing the Web With a
Screen Reader
What's all the web accessibility talk about? Surf the web with a blind user and
see for yourself! To find out more information, follow the above link.
Sources: A list Webmaster
Accessibility FAQ (11 topics) W3C Web Content Accessibility
Guidelines 2.0 (abot 10 topics) Use Screen Captures where appropriate
AJAX is an exciting new technology that is extending the Web and allowing the creation of rich Internet applications. Incremental updates to a page can improve performance and provide for more complex user interfaces and interactions via the Web. There are some basic steps that can be taken today to ensure that AJAX-enabled applications can be accessible-particularly implementing he DHTML Accessibility Roadmap technologies.
Dynamic Web Accessibility sprung from collaboration between IBM, the W3C and the Mozilla development community. As the W3C develops this new standard, IBM has implemented the necessary pieces in Firefox 1.5 and is offering expertise to help AT vendors fully support it. The Window-Eyes 5.5 screen reader supports this technology. The Dynamic Accessible Web Content Roadmap explains how to incorporate role and state information into DHTML applications.
An example of how Dynamic Web Accessibility techniques can be used to enable AJAX accessibility is a documentation site with a tree control on the left side of the page that contains the contents and a content area on the right side of the page. The user can navigate through the tree control using the arrow keys and get detailed information from a screen reader about the level and state-expanded or collapsed-for each tree node. When a node is selected, the content area on the right-hand side of the page is updated without reloading the page and losing focus within the tree control. The user can tab from the tree control into the content area and interact with the data. To navigate to new content, the user presses Shift + Tab to move focus into the tree control at the last selected node. Now the user can continue to navigate from the previous position in the contents tree-all without a page reload or re-navigation through already visited tree nodes.
According to the SecuritySpace Technology Penetration Report, more than 55% of all Web sites today contain JavaScript, dramatically affecting the ability for persons with disabilities to access Web content. New Rich Internet Applications (RIAs) render custom widgets, modeling rich desktop components to perform UI updates without having to reload the entire page - much like a graphical user interface (GUI). Legacy GUI accessibility frameworks address these issues through a comprehensive accessibility application programming interface (API) and infrastructure to foster interoperability with assistive technologies. These APIs constitute a contract between applications and assistive technologies, such as screen readers, to enable them to access rich dynamic content with the appropriate semantics needed to produce a usable alternative. No such contract exists between modern RIAs and assistive technologies, creating an accessibility gap for persons with disabilities.
· Using Flash's Accessibility Panel, developers can assign text to interface elements so that screen reader users can access them.
· In some Flash applications, developers can explicitly define a tab order for keyboard users.
· Flash accessibility depends on authors to create accessible content and on assistive technologies to support the accessibility features. Only a few currently do.
· The best use of Flash is when it supplements the content on your Web site, for illustrative or interactive uses, rather than for essential page elements such as navigation, online forms, etc.
Use Hartline as an example.
: Frames are not in and of themselves inaccessible. Keyboard users and assistive technology users are able to navigate among the various frames that comprise a web page. In order to facilitate navigation, each frame must be assigned a title (using the "title" attribute) that clearly communicates the function of the frame (e.g., "Navigation" or "Content"). Also, screen reader users should be provided with clear instructions on how and where to locate content within the frameset. See also
A growing number of software products allow web developers
to evaluate the accessibility of their web pages and sites. These tools can be
useful in identifying web accessibility problems much more efficiently than
could be done manually. However, many aspects of web accessibility are
inherently subjective, and can not be assessed automatically. All of these
products prompt users regarding accessibility issues that require human
judgment, which can help designers to learn about web accessibility. A key in
identifying which product is best is determining how clearly a product explains
and coaches users on accessibility issues. Many other variables must be
considered as well, as documented in How can I select a web accessibility
software tool?
Total Validator is an excellent site.
IBM Software Accessibility Checklist is a good checklist.
1.1
Provide text alternatives for any non-text content
The purpose of this
guideline is to ensure that all non-text content is also available in text.
"Text" refers to electronic text, not an image of text. Electronic
text has the unique advantage that it is presentation neutral. That is, it can
be rendered visually, auditorily, tactilely, or by any combination. As a
result, information rendered in electronic text can be presented in whatever
form best meets the needs of the user. It can also be easily enlarged, spoken
in a voice that is easy to understand, or rendered in whatever tactile form
best meets the needs of a user.
1.2 Provide synchronized alternatives for synchronized
media
The purpose of this
guideline is to provide access to synchronized media. Synchronized media
is defined as “audio or video
synchronized with another format for presenting information and/or with
time-based interactive components
1.3 Adaptable:
Create content that can be
presented in different ways (for example simpler layout ) without losing
information or structure.
1.2
Distinguishable:
Make it easier for
users to see and hear content including
separating foreground from background While some guidelines are focused on making
information available in a form that can be presented in alternate formats,
this guideline is concerned with making the default presentation as usable as
possible to people with disabilities. The primary focus is on making it easier
for users to separate foreground information from the background. For visual
presentations this involves making sure that information presented on top of a
background contrasts sufficiently with the background. For audio presentations
this involves making sure that foreground sounds are sufficiently louder than
the background sounds. Individuals with visual and hearing disabilities have
much greater difficulty separating foreground and background information.
2.1 Make all functionality available from a keyboard
If all functionality can be
achieved using the keyboard, it can be accomplished by keyboard users, by
speech input (which creates keyboard input), by mouse (using on-screen
keyboards), and by a wide variety of assistive technologies that create
simulated keystrokes as their output. No other input form has this flexibility
or is universally supported and operable by people with different disabilities,
as long as the keyboard input is not time-dependent
3.1 Make text content readable and understandable
People with disabilities experience text in many different ways. For some the experience is visual; for some it is auditory; for some it is tactile; for still others it is both visual and auditory. Some users experience great difficulty in recognizing written words yet understand extremely complex and sophisticated documents when the text is read aloud, or when key processes and ideas are illustrated visually or interpreted as sign language. For some users, it is difficult to infer the meaning of a word or phrase from context, especially when the word or phrase is used in an unusual way or has been given a specialized meaning; for these users the ability to read and understand may depend on the availability of specific definitions or the expanded forms of acronyms or abbreviations. User agents, including speech-enabled as well as graphical applications, may be unable to present text correctly unless the language and direction of the text are identified; while these may be minor problems for most users, they can be enormous barriers for users with disabilities. In cases where meaning cannot be determined without pronunciation information (for example, certain Japanese Kanji characters), pronunciation information must be available as well.
3.2 Make Web pages appear and operate in predictable
ways
The intent of this Success Criterion is to help users with disabilities by presenting content in a predictable order from Web page to Web page and by making the behavior of functional and interactive components predictable. It is difficult for some users to form an overview of the Web page: screen readers present content as a one-dimensional stream of synthetic speech that makes it difficult to understand spatial relationships. Users with cognitive limitations may become confused if components appear in different places on different pages.
3.3 Help users avoid and correct mistakes
Everyone makes mistakes. However, people with some disabilities have more difficulty creating error-free input. In addition, it may be harder for them to detect that they have made an error. Typical error indication methods may not be obvious to them because of a limited field of view, limited color perception, or use of assistive technology. This guideline seeks to reduce the number of serious or irreversible errors that are made, increase the likelihood that all errors will be noticed by the user, and help users understand what they should do to correct an error.
4.1 Maximize compatibility with current and future user agents, including assistive technologies
The purpose of this guideline is to support compatibility with current and future user agents, especially assistive technologies (AT). This is done both by 1) ensuring that authors do not do things that would break AT (e.g. poorly formed markup) or circumvent AT (e.g. by using unconventional markup or code) and 2) exposing information in the content in standard ways that assistive technologies can recognize and interact with. Since technologies change quickly, and AT developers have much trouble keeping up with rapidly changing technologies, it is important that content follow conventions and be compatible with APIs so that AT can more easily work with new technologies as they evolve.
http://www.w3.org/TR/wai-aria/