Cunningham - Accessibility Handbook
Here you can read online Cunningham - Accessibility Handbook full text of the book (entire story) in english for free. Download pdf and epub, get meaning, cover and reviews about this ebook. year: 2012, publisher: OReilly Media, genre: Computer. Description of the work, (preface) as well as reviews are available. Best literature library LitArk.com created for fans of good reading and offers a wide selection of genres:
Romance novel
Science fiction
Adventure
Detective
Science
History
Home and family
Prose
Art
Politics
Computer
Non-fiction
Religion
Business
Children
Humor
Choose a favorite category and find really read worthwhile books. Enjoy immersion in the world of imagination, feel the emotions of the characters or learn something new for yourself, make an fascinating discovery.
- Book:Accessibility Handbook
- Author:
- Publisher:OReilly Media
- Genre:
- Year:2012
- Rating:5 / 5
- Favourites:Add to favourites
- Your mark:
Accessibility Handbook: summary, description and annotation
We offer to read an annotation, description, summary or preface (depends on what the author of the book "Accessibility Handbook" wrote himself). If you haven't found the necessary information about the book — write in the comments, we will try to find it.
Cunningham: author's other books
Who wrote Accessibility Handbook? Find out the surname, the name of the author of the book and a list of all author's works by series.
Accessibility Handbook — read online for free the complete book (whole text) full work
Below is the text of the book, divided by pages. System saving the place of the last page read, allows you to conveniently read the book "Accessibility Handbook" online for free, without having to search again every time where you left off. Put a bookmark, and you can go to the page where you finished reading at any time.
Font size:
Interval:
Bookmark:
Beijing Cambridge Farnham Kln Sebastopol Tokyo
for more information on this offer!
Please note that upgrade offers are not available from sample content.
Many people ask me how a developer who was working on the back-end for websites got involved in accessibility. After all, it wasnt technically a part of my job description. It wasnt going to make our sites faster (though I later found out it could have that side affect). I didnt have a disability, nor did I seem to be closely associated with the disabled.
The truth of the matter: I stumbled into it. I was working on a contract at NASA, and we were required to make our sites 508 compliant in order to get them deployed. A separate group was responsible for assessing our sites then sending us exact fixes. Our websites kept failing and we found ourselves falling behind schedule again and again.
We often asked the testers to explain why something had failed, but they, like everyone else on the contract, were too busy to take time to educate a handful of developers. They gave us a checklist, which we read and were baffled by. Tables need scopes? What are scopes? Why do they need them? Whats wrong with the designers color scheme? What do you mean the contrast is no good? Why was our alt text rejected?
At the time, the resources on the Internet focused on more on policy makers and lawyers than developers. Though we found many tips about creating an accessible application, few included why these added tags made our sites easier for the disabled to use. This made it increasingly difficult to make websites that were new and innovative without wondering if we were inadvertently shutting someone out.
Though there are books that talk about 508 compliance, few focused on the people that do the actual development. They were for managers or testers, and offered few practical insights into the world of accessibility.
It took me years of battling testers, Googling, and playing with tools to get a full understanding of accessibility. I didnt think it should be that hard, though. Why couldnt all of this information be collected in one place so I could take it in within a few sittings? Why did I have to wait for issues to come up before researching how to fix them? How could we develop new technologies without patching them later for accessibility?
I decided to write a book that focused on the disabilities rather than the patches. Yes, alt text should always be used and tables should always be scoped. Whats even more important to understand is how poor alt text or tables with no scopes affect the experience of a user. Understanding a users tools and limitations helps developers and designers make the next generation of web applications without excluding anyone.
Ive also come to believe that making a site accessible makes it more usable for everyone. Though a few recommendations are exclusively for the disabled (such as alt text), many suggestions that will be made throughout the book will positively affect all users. No one likes forms that require absolute precision, and bad color choices hurt everyone. Creating a site that grows gracefully helps those on smaller monitors, such as tablets or netbooks, and including web fonts instead of images with text can make your site download faster. Good accessibility is good usability.
Being accessible is about making your website, with all of its data and functions, available for anyone, no matter how they have to use your website, or what difficulties they might have. Some people might have to use a screen reader, where the content of a site is read to them. Others may rely on subtitles and transcripts for audio content. Still others may be unable to use a mouse, or they may be using an adaptive device that works only through the mouse. They may need to override a websites styling in order to make it more readable for them.
In short, no one should be excluded from using your website simply because they have to access the Web in a different way.
Being accessible doesnt mean stripping your website of any advanced functions because someone is using a screen reader, or might have issues using a mouse. It doesnt mean a return to the days of unstyled web pages, or hiring a group of people dedicated to making your products accessible. Accessibility, if kept firmly in mind during development, can be done without significantly increasing overhead, and can even improve your website for your standard users.
In 1998, Congress passed an amendment to the Rehabilitation Act, requiring that all websites created for the United States government be accessible to everyone, in spite of individual handicaps. This amendment was Section 508, so often, web accessibility is referred to as 508 compliance. While the original act (passed in 1973) had its own 508 section in regards to technology, it was toothless until 1998, when standards were introduced. It was determined that any website paid for by federal funds must follow the requirements laid out in this amendment.
An out was written into the section, allowing for websites to get a waiver if their audience was small, and confirmed to have no one with any disabilities. With the growing number of disabled joining the ranks of not only the government, but also its contractors and affiliates, these waivers are growing more rare. Its difficult to prove that your audience will never include anyone with a disability, so this waiver is usually limited to top-secret projects or projects with an extremely limited timeframe (such as a workshop or one-time meeting).
The act covers anyone with a disability, but its interpretations often focus on three main groups:
The visually impaired
Those with hearing impairments
Those with physical impairments
Why not just call the first two groups the blind and the deaf? Section 508 takes a broader stance, considering those with low-vision and color blindness, as well as those who may not be completely deaf.
Obviously, the main benefactors are those with vision or hearing issues, or who have physical limitations. As websites grew in complexity, many people in these groups were left behind. Tables used for layout kept screen readers from performing correctly. Complex layouts refused to grow gracefully, causing issues for people with low vision. Menus that dropped down, then snapped back at the slightest wavering of the cursor caused websites to be impossible to navigate for the motion impaired.
Theyre not the only benefactors, however. A website that is accessible for the disabled often gains the benefit of becoming easier to use for everyone. Narrow clicking margins are annoying to those with full mouse control as well as those with motion disorders. Websites that dont grow gracefully can be difficult for people using different size monitors. Someone on a low bandwidth connection (for example, tethered to a phone with a low data cap) might need to turn off images while surfing.
Also, its important to remember that not everyone who is disabled has been disabled forever or will remain disabled. A person who has broken her dominant arm learns very quickly how difficult websites can be to navigate without a steady mouse. A person without headphones will have trouble with websites that require sound. And a person who has forgotten his glasses will be subjected to websites that dont deal with large text gracefully.
Font size:
Interval:
Bookmark:
Similar books «Accessibility Handbook»
Look at similar books to Accessibility Handbook. We have selected literature similar in name and meaning in the hope of providing readers with more options to find new, interesting, not yet read works.
Discussion, reviews of the book Accessibility Handbook and just readers' own opinions. Leave your comments, write what you think about the work, its meaning or the main characters. Specify what exactly you liked and what you didn't like, and why you think so.