Introduction

Web accessibility for people with cognitive disabilities and learning difficulties is one of the most overlooked subtopics of general web accessibility,
despite it affecting the largest numbers. A large part of it is that there are so many conditions to understand in this area (far more than say visual
or hearing impairments) and a lack of educational information available for learning about it.

In this article we will cover a few of the problems users with cognitive disabilities may have that can affect their ability to use the Web, as well as
the things that developers can do to alleviate these problems and things they should avoid. A lot of what is covered will be well known and common sense to many, but is here for completeness.

What are Cognitive Disabilities and Learning Difficulties?

As with any aspect of accessibility, here we are less interested in specific conditions than we are with how they impact a person’s ability to use a website. These conditions affect a web user’s ability to perform one or more mental tasks. This includes problems with:

• reading text
• memory
• problem solving
• keeping focused (attention span)
• computation (for example calculations)
• non-verbal learning (for example difficulty with written materials)

For example, let’s have a look at some basic personas:

• Steve has problems processing text, particularly when words are spelt incorrectly or when sarcasm or metaphors are used (this is most likely dyslexia).
• Alison has short-term memory problems with what she sees and hears. It is difficult for her to remember what she has already entered in long forms or previously read in articles split into multiple pages.
• Jeremy has difficulty with problem solving. He struggles with unfamiliar circumstances, such as links to new places in a website or unclear form input error messages (this could be as a result of intellect, emotional or executive function impairments).
• Emily finds it difficult to focus on tasks, particularly when a web page has moving adverts or multiple pop-up windows.
• Thomas has problems with numbers; it can be difficult for him to estimate the total cost of items when buying online or to solve simple maths-based questions asked on some comment forms to prove he is not a spambot (this is most likely
  dyspraxia).
• Kate can have problems associating a representation of an object with the object itself, such as associating a picture of an apple with a real apple. She finds it easier to understand audio information than written or pictorial content.

Users can sometimes have a combination of cognitive disabilities and learning difficulties, and they may also have physical disabilities. It is important to be aware of the range of conditions that might affect your users, but at the same time you must avoid strict categorisation as every person is unique in their abilities — it is rarely simple, and there really is no one size fits all solution. For example, someone who is in the autistic spectrum
may have none of the issues listed, but as this spectrum is concerned with making human connections and communication, certain visual or written nuances that would be obvious even to someone with a severe learning difficulty that affected the processing of information may be missed by someone in this spectrum.
And someone with severe ADHD (inattention and hyperactivity) can find any task way more frustrating than what is considered as normal.

Areas to consider

You may find it difficult to create a web site that is accessible to all users with cognitive disabilities and learning difficulties because of the range
of issues you need to consider.

You might find that a solution for one user is a hindrance to another, for example images could potentially be a distraction to someone who prefers text, even though combining content types is your best hope for universal accessibility. If you have a specific target group you can tailor content for that group, otherwise you have to tailor content for different information representations for different groups.

By following some simple guidelines you will be able to make your content available to as wide an audience as possible. A lot of this is fairly general web design best practices, but that’s what enables a lot of accessibility! Framing them in the context of cognitive disability should give you a better understanding of the area.

Consistency

The first thing you should think about when designing your content is consistency. Users should be able to learn what to expect from each new page of your site — the various features should be consistent with previous pages, in terms of style, location and function.

What, in particular, should we be aiming to make consistent? Lets go through them.

Navigation

After the content itself, the site navigation is possibly the most important thing to get right. Its position and functionality should not change across a site, and it should be easily identifiable as navigation, with intuitive menu options.

Fonts and Font Sizes

Do not use too many different fonts, and treat them as you would a colour palette. Stick to a small number, perhaps one font for headings and one font for body text. Introducing a lot of variation serves to introduce distractions and noise, and this is something we want to avoid at all costs.

Interactive Elements: Links and Buttons

It is important that users of any kind can recognise a link on your site. Links on a site need to follow the same style, and need to behave as a user would expect. Positioning, relevance, purpose and destination are all very important here.

The same goes for buttons, and there is much to be said for leaving buttons and other form controls as they are styled by the browser as this is what many users expect forms on the Web to look like. This not only delivers consistency across your site, but across all sites. Controls that are already familiar to a user will likely be less confusing.

Structure

It is important that content is well organised and structured. HTML gives us a limited set of elements to organise our content. Although we may sometimes find this restrictive it can actually be a good thing because it helps us be consistent as well. This section discusses the different facets of structure.

Headings

Headings and subheadings should be clear, meaningful and properly nested — they are a guide to the content on a page. Ideally it should be possible to get a good idea of what the content is about just by reading the headings.

Lists

By their very nature lists require more concentration to scan through and comprehend. Each item in a list should be short and concise, and further visual grouping of a list (eg using a different background colour to the rest of the page) – if you have a complicated concept to explain start with a list and then expand on each item under its own heading.

White space

White space is important for structure; without it all elements will merge in to one block and become incomprehensible. Look for good separation between headings, paragraphs, block quotes, etc. Pay particular attention to the spacing between columns of content; wide gutters or clear delineation with vertical
borders can help.

Clear Differentiation Between Content Types

Use colour, font weights and other styles to differentiate between types of content, for example a quoted phrase could be emphasised, form labels could be strong. This makes it easier for users to determine the type of content they are looking at a glance.

Focus

Most users of websites are task-driven – they have a task that they want to perform, and they want to do it without distraction, as quickly as possible. It can be easy to distract attention from your content, so there are certain things to avoid, which we shall talk about now.

Contrasting Blocks of Colour

It is natural that a users eye will be drawn to the more colourful areas of the page, so avoid overly bright or intricate side columns or other needless distractions. You want to encourage users to be focused on the most important page content or functionality.

Unexpected Sound

Avoid sounds that are played without the user specifically interacting with the source – this again will cause confusion.

Animations and Other Moving Content

Movement on a page can be very distracting, especially if it happens automatically, without the user having any warning that is going to happen. The only place there should be movement is on the element the user is interacting with at that moment, for example a highlight on a navigation menu option, or playing
a video when the user chooses to.

Pop Ups and New Tabs

Pop up windows and automatically loading content in new tabs moves attention away from the whole page — more confusion. In addition, popups usually tend to be adverts, therefore users tend to dismiss them regardless of their content.

Readability

Good readability guidelines apply to all text on your page, whether in navigation, graphics or just plain content. The most important part of any page is the content, and the following guidelines will help you make your content as readable and intuitive as possible.

Adequate Text Size and Line Height

A font size of 10px or 11px is often considered an acceptable minimum, however I would recommend 12px or 13px depending on the font (I am talking computed sizes here — you would of course set text size using a relative unit such as ems or percentage in your CSS). Although browsers have controls to adjust
font sizes or zoom the entire page, there are no guarantees that a user will know how to use them.

Line height should be approximately one and a half times the font size.

Limited Line Length

Long line lengths can be difficult to read in some circumstances. Contrary to popular belief not all users have problems with long lines, but users with reading problems often do. Stick to a maximum of 70–80 characters of text per line.

Colour Contrast

As for other users, good contrast between foreground and background is important. In addition, using colour to differentiate between links and regular text can help.

Short Paragraphs

Write short paragraphs, each one focused on a single point or idea.

Transformability

Transformability means that your content can be changed in ways to suit different users. We will look at various mechanisms you can employ to support transformability in this section.

Support Text Resizing

The most basic type of transformation is changing text size. Your design should be able to support a font size increase of at least 200%; 300% preferably.

This is less of an issue now that most browsers support full page zooming, but there are still users that would prefer to increase font size without changing the width of the page, the images, or the containing columns.

Support user styles

Make it easy for users to apply their own styles via user stylesheets. Write good clean CSS, using low specificity on selectors and avoiding the use of !important.

Ensure it Works Without Images, Scripting or Styles

Test that the site works without images, scripting or styles at all. This is the ultimate fallback for all users in all situations, and it makes it easier for them to provide a usable baseline like this, rather than them having to write their own style sheet. It is also a good test of the structure of your
content.

Provide an API or Feed

Provide an API or a feed to allow others to re-format your content. Ultimately it may not be possible to cater for all users on one site, but if other developers are able to take your content and reformat it for different situations, you will reach an even wider and more diverse audience.

Twitter is a great example of what can be done with an API. Not only is content and the ability to tweet available from the website but there are many different client applications that can be tailored to different users needs.
Accessible Twitter is an alternative to the Twitter website, designed and optimised to be easier to use by disabled users.

Another example is Easy YouTube,
created by Christian Heilmann. It is an interface to YouTube specifically designed for users with learning difficulties. As Christian himself says in the documentation, without the availability of various APIs this would not have been possible.

Content

Now on to the content itself, the most important part of a site. If you have marked up and structured your content correctly then it should be convertible to other forms, but if the content itself is broken then you have gone wrong from the beginning.

Spelling and Grammar

Most users can probably get some meaning from content that has grammatical errors or spelling mistakes, but they can render a word or sentence completely meaningless to users with reading difficulties.

For commercial sites I would strongly advise using the services of a proof reader or professional copy editor.

For sites without a commercial budget, spell and grammar checkers are built in to most applications used to write content, so use them, but make sure you also give your content a human proof read as best you can.

Definitions of Terms

Define any abbreviations, acronyms or technical terms. Provide a glossary for complicated or technical subjects. Avoid jargon if you can, but not to the point of removing clarity from the content.

One Subject

Stick to the subject of your page; be focused and avoid digression.

Summarise

Summarise the content of your page as an introductory paragraph. This allows your user to determine if this is the content they are looking for early on to avoid frustration.

Mix Content Types

Different users may find different forms of content easier to consume. For one user lots of images and less text may be more understandable, whereas for another the same content spoken in a video might be better.

Wherever resources allow, try to provide your content in multiple formats. Don’t forget to caption videos and transcribe audio content.

Obviously this can make content very editorially intensive, so is not possible in all cases, but if you have a product to sell and you include a text description, images showing individual features and a video clip of the product in use, this will not only constitute a better sales pitch, it will also allow users
to pick the content type that works best for them.

It is also important to try and avoid making mixed content distracting. As previously mentioned, a solution for one user may be a hindrance to another. Sensible designs and interactions are key here. If you are mixing text with images perhaps separate the two rather than interspersing the images within
the text. Display the images in a slideshow rather than showing them all at once, and try and provide the same information with images alone. A user can then choose to read the text or go through the slideshow to get the same content.

Conclusions

You may think that a lot of the points made in this article are nothing more than common sense, and you would be absolutely right! The good news is that the best strategy for creating a site accessible to those with cognitive or learning difficulties is to provide clear and straight forward content in an
easy to use interface with few distractions. This is what we want to provide our users with in most circumstances anyway, so it only takes a little more care and thought to avoid the pit falls.

The benefits go beyond what is traditionally thought of as accessibility as well. Something as simple as good grammar can greatly increase comprehension, especially for readers who are not fluent in the language a document is written in.

There is some bad news unfortunately – a single interface or style of content is never going to be able to cater for all users in all circumstances. This gives further weight to the idea of exposing content via a good API or feed. The same content can be repurposed for display in a different format, on other web sites, or on devices such as mobile phones.

Reproduced from http://dev.opera.com/articles/view/cognitive-disability-learning-difficulty/

July 30, 2010
by Jared Smith

WebAIM is often approached by individuals and organizations concerned about “ADA compliance” of their web site. This is a bit of a misnomer. The Americans with Disabilities Act of 1990 pre-dates and does not address web accessibility at all. That may soon be changing.

This week the US Department of Justice announced that they are considering expanding the scope of the Americans with Disabilities Act to cover some web sites. This is simply a request for comments.
The Dept. of Justice will consider your feedback in any formal proposal to expand the ADA.

This announcement has brought much dialogue in the development community, particularly on this popular Slashdot story.
It is clear that there are many concerns and misconceptions about what this would mean. There are also many deep-rooted, philosophical arguments against the ADA in general that have come to light. Web regulation is tricky. As a web accessibility consultancy, ADA requirements will certainly bring us more business (though admittedly, our goal is to work ourselves out of employment by making the web entirely accessible – something not likely to happen in the near future). The ADA and its implementation is far from perfect, but I believe that we live in a world where people with disabilities should have opportunities to engage in commerce and online activities uninhibited by discrimination. This has generally not occurred to date.

So, with the assumption that the Department of Justice will recommend that the ADA cover some web sites, I’d like to address some of the concerns and misconceptions about the ADA’s potential application. These all come directly from the Slashdot story comments.

“Why do I have to make my personal web site compliant?”

You don’t. Private web sites would not be covered by the ADA. Government sites and websites that provide “goods, services, and programs to the public”, including shopping and other publicly accessible e-commerce sites, will likely be covered. Where or how this distinction will be made is unknown. It is quite possible that, like physical buildings, different types or classes of web sites would be required to meet different levels of compliance.

“People with disabilities do not use my site”

This same argument was heard when the ADA became law in 1990. Bus operators, for example, complained that they should not have to make their buses accessible because people in wheelchairs did not ride them. Of course they did not, because they could not.

Are you sure people with disabilities do not use your site? If they don’t, is it because it is not as accessible as it could be? There is no way to detect
whether a visitor to your site has a disability.

“My content can’t be made accessible.”

The ADA does and would require reasonable efforts and accommodations. Nothing in ADA or any other web accessibility guidelines would require that you fundamentally change what it is you do with your web site. Art galleries would not be required to pull the plug on their site because blind users can’t see their art.
Music vendors would not have to close their doors because the Deaf can’t listen to music.

“The web will go back to looking like 1990.”

Most web accessibility happens ‘under the hood’ of a web site. Any accessibility-related modification to the visual design of a site almost universally
increases the usability of that site to all users. For example, having sufficient contrast is required for users with some visual disabilities, yet good
contrast makes the site more readable by everyone. Captions are necessary for users with auditory disabilities, yet can provide great benefit to anyone
watching web video.

Modern, stylish, well-designed, interactive web sites and web applications can fully support accessibility. In fact, they can do so better than any site
built in the 1990s.

“Why all the effort for so few people?”

Conservative statistics indicate that at least 8.5% of the population has a disability that would affect internet use. This may not seem significant, though
I bet that most web developers spend time ensuring compatibility with browsers that are used by fewer users.

Yes, web accessibility requires some effort, but it is not overly burdensome if you build or purchase a usable site that is built using web standards. Accessible web design is good, usable web design. Efforts made to improve the accessibility for people with disabilities will likely make the site better for everyone.

“There is no economic benefit to being accessible.”

There are certainly costs associated with web accessibility. But there is also potential for great benefits. Consider viewing accessibility as more than
simply opening the door to 8.5% of the population, but as an opportunity to directly target that audience and their multi-billion dollar discretionary
income.

The web is generally not very accessible now. Those businesses that are ahead of the curve with ADA compliance have the potential to greatly benefit from receiving the business of this audience. Apple, for example, sees this potential; they’ve implemented high levels of accessibility into their new products, such as the iPhone and iPad, despite no regulatory requirement that they do so.

“Accessibility regulations will force me to close my small, online business.”

Perhaps. Accessibility does not come free. The Department of Justice will consider the burden and economic impact when considering whether and how to regulate small business web sites. The further your site is from being designed to web standards, the more expensive and difficult it will be to make accessible. The cost is generally inversely proportional to the accessibility knowledge of the developer building the site.

Thus, there is a need for better web development tools and better educated web developers who are committed to building things with standards in mind. This will come over time; and the regulations will certainly allow for this. When the ADA originally became law, there were many contractors that specialized in making physical spaces accessible. Now, there are simply contractors – nearly all of whom have the technical knowledge to naturally construct things to be accessible. The same is likely to happen with the web – and that is a good thing for everyone.

As noted above, accessibility can be an economic boon, especially for the businesses that do it right and do it early.

“I can’t just make my website accessible over night.”

And there will be no requirement to do so. If web compliance is at all similar to accessibility of physical spaces, there will be allowances for legacy
content, transition plans, exemptions for certain types of content or businesses, etc.

The ultimate goal is to become more accessible over time.

“I shouldn’t have to hire a lawyer to make sure I’m compliant with thousands of pages of State and Federal regulations when I publish a web page?”

Accessibility guidelines can be daunting, but they are not overly technical. ADA guidelines will almost certainly mirror or at least reflect the
WCAG 2.0 accessibility guidelines. There is a wealth of information ( including this WCAG 2.0 evaluation checklist)
available here at WebAIM.org and elsewhere.

One would not need a lawyer to verify compliance. Only in the case where a site remains inaccessible and discriminatory with no effort to improve might
a lawyer be needed.

Reproduced from http://webaim.org/blog/the-ada-and-the-web-concerns-and-misconceptions/

For the longest time I’ve was advocating against the Portable Document Format
(PDF), none of them were accessible to my screen reader so I”Settled”
for plain text, to me it was the lesser of evils. At no time did I ever care
for the Microsoft Word format, next to an inaccessible PDF it was just as bad.

Read more at
http://www.aoda.ca/?p=507

By Geof Collis
Bad Eyes Design & Consulting

For the longest time I’ve was advocating against the Portable Document Format
(PDF), none of them were accessible to my screen reader so I”Settled”
for plain text, to me it was the lesser of evils. At no time did I ever care
for the Microsoft Word format, next to an inaccessible PDF it was just as bad.

Read more at
http://www.aoda.ca/?p=507

Amongst the basic skills that fledgling designers and developers should know is the art of website validation.

Website validation consists of using a series of tools such as W3C’s Markup Validation Service that can actively seek out and explain the problems and inconsistencies within our work.

While the use of such tools has benefits (in the sense of being an automated fresh pair of eyes), a worrying trend of either over or under-dependence keeps rearing its ugly head.

This article aims to underpin the inherent issues of validating your websites through automated web services/tools and how using these tools to meet certain requirements can miss the point entirely.

Current Practices

Before we begin critiquing the valiant efforts that our noble code validators undertake (they have good intentions at least), it’s important to note that
with all things in life, a balance must be struck between the practical application of validation and common sense.

We live in a modern era of enlightened thought where web standards have become a white knight, always charging towards slaying code which fails to best represent our work.

But while current practices actively request and promote using these validation tools, no web-based tool is a substitute for
good judgment.

The above code may not validate, but it’s acceptable to use if there’s no good alternative.

Not Using Valid Code

The case for under-dependence can be seen by examining the Alexa Top 100 sites
and using some basic W3C validation tests.

The eye-watering number of errors these popular sites produce (which escalate into the hundreds) is rather unsettling for some.
The problems for those ignoring validation altogether has been well-documented to the detriment of end users (as has the justification for following web
standards) and as ignoring validation entirely makes you as guilty as those using it as a crutch, it’s worth recommending not to forsake these tools even
with their shortcomings.

Amazon’s front page doesn’t validate, but it doesn’t mean they don’t care.

Blindly Following the “Rules”

The case for overdependence is something we need to worry about too. Those who form drug-like addictions to making everything validate or meet a certain criteria just to please an innate need for approval are on the rise.

While ensuring your code validates is generally a good thing, there are professionals who take it to such an extent that they resort to hacking their code
to pieces, ignoring new and evolving standards or breaking their designs just to get the “valid” confirmation. Quite a price for a badge.

And there are even people who think validation automatically means everything’s perfect, which is worse.

There are a lot of tools out there, but you should be wary about which you rely upon.

Context is King

The thing about validation tools that beginners (and some seasoned professionals) often overlook is the value of context.

The most common problem that validation tools encounter can be summed up in the sense that they are only machines, not humans.

You see, while checking if the code you wrote is written correctly, on the surface, may seem like a simple task, that sites meet disabled users’ needs,
or that text on the screen is translated properly — the very obvious truth (for those who understand the mechanics involved) is that the complexity of
how humans adapt cannot be replicated effectively.

What does this design say to a machine? Nothing! It only sees the code and that’s it.

You Can Make Decisions That Robots Can’t

If you’ve seen the “The Terminator” movie, you probably have a mental image of a not-too-distant future where machines can think like humans and therefore make decisions based on adaptive thought processes, such as being able to intelligently and emotively know what makes sense.

But unlike that film, the levels of which such tools can understand context and meaning (beyond what’s physically there) simply doesn’t exist today—though that’s probably a good thing as we don’t want the W3C validator going on a rampaging killing spree against <blink> tag users, right?

There may be a time where machines are as smart as humans, but that’s not today.

Code Validation

The most notable form of code validation in use today is that of the W3C
HTML and CSS validators.

The level of obedience from some designers and developers to ensure their code validates is best reflected in the way many websites actually proclaim (through the use of badges) to the end user that their code is perfect (possibly to the point of sterility).

Proclaiming the validity of your code doesn’t mean what you’ve produced is perfect.

This reminds me of the way software developers proclaim awards from download sites as justification to use their product. As I’ve mentioned previously,
however, the W3C validator (despite its association) is not perfect.

Failing Because of Future Standards

It’s an established fact that the W3C validator not only examines the structure of your site but the elements or properties themselves (though they don’t
understand semantic value!).

The key issue with such due diligence from these tools is that elements which are not recognised (such as those of upcoming standards like CSS3 or equally valid proprietary extensions) are often misinterpreted by developers as “unusable” or “not approved” and therefore get rejected.

Taking Stuff Out For The Sake of a Badge

It seems rather amusing to me that people are willing to omit the value of somewhat acceptable but non-standard code — CSS3 attributes specific to particular browsers, for example — to satisfy the validators, like they’re trying not to anger the Tiki gods.

What ends up happening is the validators themselves make it seem like legitimate practices which defies convention are automatically wrong, and this results in a strange psychological condition in which people too quickly limit their own actions for the sake of a machine (or the ideology it provides).

While it makes sense not to use deprecated/future-standards code, validators simply can only test against what they know.

Nothing says: “I want approval” like these well-known badges of honour from the W3C.

It should be made quite clear that people who proclaim HTML and CSS validation on the page are doing so to make themselves feel better. Unfortunately, none of your users (unless you cater specifically and strictly to web designers and developers) are likely to know what HTML even is, let alone understand or trust what the fancy validator badge is telling them!

Web Accessibility Validation

If you want a case where validators totally miss the point and where their limited testing ability is abused (to proclaim the work which is being tested
against is complete), you need look no further than the accessibility validation services like Cynthia, the now debunked “Bobby” and their kin.

One key issue with validators are that they can only test against what they can see (in almost all cases this only accounts for source code).

While some of the issues in WCAG can be resolved with some helpful coding (like alt attributes on images), code doesn’t account for everything in accessibility.

Cynthia “says” your site meets WCAG guidelines, but it’s often missing several points!

The Only Way to Test for Accessibility and Usability is through People

Accessibility and usability are highly subjective issues that affect many people in many different ways, and often the way code is presented (or even the
content) does not establish where key problems may lie.

Too often beginners actively use the checklist nature of these services to claim their work is accessible on the basis that a validator covered what it
could (omitting the complexities which it cannot account for – such as the sensory criteria and their inhibiting factors). This key lack of understanding
and the wish for a quick fix showcases that reliance of these tools isn’t ideal.

How many validators can tell you how easy to read your content is? How many of them run a screen reader over the top of your site to denote the way a blind user may find your information?

While some factors can be mechanically replicated, the problem is the tools primarily focus on code alone and therefore miss the bigger picture (and those who rely on them also get caught up in this lack of awareness).

Without the background knowledge of how such web or software applications function, a scary number of people simply use them as an alternative to properly learning what they’re doing.

Do you speak Latin? No? This content would pass as accessible, readable and valid!

The state of accessibility tools is so bad that I advise people not to use them in favour of proper human checking.

The myth that tools can do things at an equal skill level of a human is far from the truth and while the W3C validators can be helpful, accessibility tools
are too biased to be credited.

Translation Troubles

Confusion (as denoted above) in relation to such validation tools comes in many forms. Whether it’s the mystical messages the W3C validator produces (which beginners may not understand), the lack of fair warning that these tools should be used “as part of a balanced diet”, or that these tools are often much more limited in what they can offer than you would be led to believe.

One of the more comical examples of automated tools going crazy can be seen through translation tools such as those provided by Babel fish or Google, which again proves that nothing is better than humans.

Google Translate is popular amongst websites for giving “rough” language translations.

One of the key elements of human languages is that words can have more than one meaning (and deciding which instance is in use can be tricky for machines – a case of context).

In accessibility, the issues of vision can be anything from total loss of eyesight right down to a case of color blindness. Because of this, a language
translator will simply go for a literal meaning of the word rather than the context in which it’s used which can reduce your content into a scrambled illegible mess which doesn’t help your visitors (especially if they have learning difficulties).

While of course translation tools aren’t code validators, they do in fact perform a similar service. By taking a known list of criteria (whether code, words
or something else), they attempt to check that something accurately portrays what it’s intended to.

If, however, you use something it doesn’t expect (like a new word in translation tools or a new property in the W3C validator), it will report it as a failing
on your behalf.

Such reliance on validation tools for “perfect” results is therefore unjustified and can limit yourself to the detriment of your audience.

A Translation Exercise to Test the Idea

If you take a block of content from a website, paste it into Google Translate,
translate it to another language, and then translate it back into English, you’ll see for yourself how badly these validators of content conversion are
at the job. It can give you hours (if you’re really that much of a geek) of comedy in a few sessions!

See how the same sentence has been wrongly translated? It’s not uncommon!

The Silver Bullet

Knowing that validation tools are far from perfect is an important lesson to learn. Many people assume that such tools are an all-knowing oracle that accounts for everything your users or browsers may suffer.

While it’s wrong to say that these tools aren’t useful, it’s important to understand that the validation tools should not be used as a guarantee of accuracy,
conformance or accessibility (in your visitor’s best interests).

A valid site should never be achieved if it sacrifices the progression of web standards, unjustly acts as a badge of honour or attempts to justify the end
of the build process.

Knowing how and when to use code and the difference between right and wrong
is a tough process we all undergo during our education.

The truth about validators is that sometimes being invalid is the right thing to do, and there are many occasions where a “valid” website is nowhere near
as valid as you might like to think it is in terms of code semantics, accessibility or the user experience.

I hope that all of this will serve as a wakeup call to the generation of coders who either ignore or abuse validation services. These tools are not a silver
bullet or a substitute for being human!

Reproduced from http://sixrevisions.com/web-standards/problems-with-using-website-validation-services/

Despite a range of legislation and best practice advice, cyberspace is still far from equitable for those of us “non-standard” enough to be using
adaptive or assistive technology.

There is plenty of guidance available, from legislation such as the Disability Discrimination Act and the Disability Equality Duty, specific recommendations in the form of the Web Content Accessibility Guidelines (WCAG) 2.0 and even an enforcing body, the Equality and Human Rights Commission.

But the majority of websites are still not accessible to those dependent on using keystrokes instead of a mouse, nor those using screen-reading technology or voice recognition software. In addition, many of these tools do not work on a mobile platform, so anyone using a handheld device may be similarly prevented from achieving full access. The majority of providers still flout the guidelines, ignoring even the most basic requirements such as adding “alt text” for pictures and ensuring that functionality of content is operable through a keyboard interface.

Accessibility Awareness

Two main approaches have been adopted to try to change the situation.

The first is to raise awareness by improving the understanding and skill set of web teams. Standards such as WCAG 2.0 and organisations such as
OneVoice for Accessible ICT Coalition are making tremendous strides in this area.

But a growing impatience with the current circumstances has been the motivating force behind the second approach to change the situation – a series of third-party solutions devised to improve the situation for those who are struggling to navigate their way around cyberspace.

One such system is Texthelp Systems’ BrowseAloud product,
which reads (accessible) web content aloud, thereby assisting people who find it difficult to read text online, including those with literacy difficulties,
dyslexia and mild visual impairments, as well as non-native speakers.

Another successful add-on for readers with special educational needs is a symbol-based system such as that produced by
Widgit. Widgit’s augmentative software enables website owners to assist visitors to their site by producing symbols of suggested meanings when their mouse hovers over a word.

Some such enhancements – plug-ins or add-ons – require buy-in from the website provider, while others are installed on the user’s machine and enhance the functionality of the browser. They often represent an accessibility bonus to a site, but their use should come with a note of caution.

Robin Christopherson, head of accessibility services at
charity AbilityNet and himself blind, says: “These third-party solutions fall into two categories – those that enhance accessibility, and those that patch inaccessibility. Great tools such as Widgit’s plug-in can help extend the level of access way beyond what even the most accessible sites can provide, in this case enabling
those with very significant literacy difficulties to read a site by recognising symbols instead of words.

“Other browser plug-ins, or site add-ons, help get over some of the main accessibility shortcomings exhibited by a website. These tools are just as useful to the disabled surfer, but this ‘patching’ of inaccessibility should not be seen as a ‘get-out clause’ for site developers. They fulfil immediate and
short-term requirements, but in the long-term are they not merely patching the inadequacies of inaccessible sites, which, after all, are unlawful, and
therefore at risk of litigation?” he says.

“Responsibility falls quite clearly at the door of the site owner to raise the bar and let disabled people in.”

Community-Driven Web Aids

Christopherson highlights the emergence of empowering, community-driven innovations such as
WebVisum to illustrate the point. Webvisum fulfils a vital need to enhance accessibility, while potentially easing pressure on site owners to raise their game. Arising out of genuine need, WebVisum is a browser add-on, available for Firefox, that provides tools and services that overcome some aspects of inaccessibility for blind and vision-impaired users – minimising their dependency on help from others.

With WebVisum – a tool requiring membership by invitation only – the user community drives image tagging and page enhancements. It offers dozens of features which make life easier for blind and vision-impaired web surfers, such as high-contrast page viewing, link and focus highlighting, and, perhaps most importantly, it provides automated and instant Captcha image solving.

Captcha codes are the most widely used verification scheme on websites to ensure that web content is accessed by humans only, but they are the bugbear of accessibility campaigners. Captcha has gained much popularity for its apparent effectiveness and ease of implementation, despite the obvious drawbacks the codes present to the vision-impaired.

And however efficient Captcha may seem to be, it has not prevented the creation of so-called “Captcha farms” in the Far East and Asia where workers are
paid subsistence wages for “solving” thousands of codes a day to feed the insatiable spam industry.

WebVisum allows the blind user to press a keystroke that submits the Captcha image to a service that, within seconds, returns the code and automatically copies it to the clipboard.

But even WebVisum cannot handle all Captcha images. The introduction of a series of random logic-based questions, such as the service provided by
textcaptcha.com, is a far more accessible alternative to the graphical option, but this has yet to be embraced widely. While the perception persists that tools such as WebVisum can handle all Captchas, perhaps this is not likely to change.

“Being blind I definitely appreciate the usefulness of a tool that can solve Captchas and add missing text labels to images. WebVisum even makes those tags available to every member of the WebVisum community so images come up already labelled,” says Christopherson.

“Everything that can reduce the frustration of a broadly inaccessible web is in principle a good thing. However, a successful community effort risks a consequent reduction in the level of negative feedback to offending websites. Such a decrease in pressure is sure to make them feel less inclined to sharpen up their act.”

Making Visual Adjustments

IBM’s free Web Accessibility Toolbar is another user plug-in for Internet Explorer which can over-ride hard coding and make live visual adjustments to the site content to enhance usability. The toolbar offers a wide variety of accessibility features, including easy font size and colour contrast adjustments,
magnification of a small portion of the screen, as well as the option of having the text read aloud with adjustable speech speed and volume controls. Once again though, a website’s inherent flaws can cause major problems.

“Reformatting using these tools often results in overlapping, cropped or disappearing text. If the site has not considered what will happen when text is
resized by the user, then a tool added on to make this possible will often have undesirable effects,” says Christopherson.

Although he welcomes the introduction of such add-ons, Christopherson says they are by no means the total answer to inaccessibility. “Patching can be a very patchy business indeed, and nothing can substitute for truly inclusive design,” he says. “Despite the availability of all these user tools, the ultimate responsibility for accessibility still lies firmly with the website itself.”

Reproduced from http://www.computerweekly.com/Articles/2010/05/27/241383/How-to-make-the-web-accessible-to-everyone.htm

Let’s get some reality on the web accessibility debate.

We all know about WCAG 1, we have all at least had a look at the associated checklists.  If you are lucky you may have glanced at
WCAG 2.

We all have been developing and designing our sites with semantic content, in compliance with W3C guidelines,
using progressive enhancement for the interactive components, unobtrusive Javascript, and
graceful degradation of the pages for legacy browsers.   Maybe used some of the attributes of ARIA.
Sure that’s a no brainer.

We know that doing this will solve most of the accessibility issues. So much so that one would think that the
cause for accessibility and universal design was over.  Right?

No, wrong.

Read more at
http://manwithnoblog.com/2010/05/20/kill-accessibility/

Introduction

One of the myths of web accessibility is that people with disabilities benefit from text-only versions. The truth is that practically nobody with a disability
benefits in any way from a text-only version at all. Text-only versions may be of some benefit to people with slow Internet connections, but not to people
with disabilities (unless they happen to have slow Internet connections). In almost every case, it would be better—much better, usually—to fix the original
version than to create an alternative text-only version.

Why Some People Think Text-only = Accessible

Web accessibility novices are usually most familiar with the accessibility issues relevant to blindness. When they think of web accessibility, they think
of screen readers and alt text for images. They don’t think nearly as much about people who are deaf, people with motor disabilities, or people with seizure disorders, color-blindness, low vision, or cognitive disabilities. With this heavy bias toward blindness, it makes sense that a text-only version could benefit users who don’t need images, graphics or illustrations. According to this logic, creating a text-only version could save developers some effort (and money) because they wouldn’t have to insert graphics, and wouldn’t have to add alt text for them. Parts of this logic are true. People who can’t see graphics don’t need graphics. Adding alt text is an extra step that could be avoided by not including any graphics at all. Other parts of this logic, however, don’t hold true.

The Case Against Text-only Versions

Bias against the full spectrum of disability types

The most important argument against text-only versions is that they do not accomplish what they are intended to accomplish. Text-only versions accommodate only one kind of disability: blindness. Web sites with text-only versions are evidence that the site’s designers do not understand web accessibility. They may have created the text-only version thinking they were making the page accessible, but they neglected to address the needs of all other disability types.

The need for graphics and visual presentation

Consider people with dyslexia or cognitive disabilities. How can a page full of text—and only text—increase accessibility for these individuals? Some of
these individuals could benefit greatly from more graphics, more multimedia, and more CSS styling. A text-only site is quite counter-productive in these
cases, and is actually less accessible than the original graphical version.

“Regular” web pages are more transformable

In a sense, the regular version of a web page—even if it includes graphics and styles—is already a text-only version. Screen readers can only read text,
so they ignore the graphical and stylistic elements of web content. Screen readers don’t attempt to interpret the visual information of an image, they
simply read the alt attribute, which is already in a “text-only” format. For the most part, the visual presentation and CSS styles have no impact whatsoever on the way a screen reader reads the content. In other words, what screen reader users experience is a text-only version of the web page.
The full version was transformed into a text-only version.

However, there are no technologies available to the average consumer to transform text-only versions into graphical versions, or to create appropriate styles where none existed before. Text-only versions are not easily transformable into other formats.

“Separate but equal”

Another important argument against text-only versions is that it creates a kind of Internet apartheid of supposed “separate but equal” versions of content.
As with racially segregated classrooms, ability-separated web sites are rarely equal when separate. Designers rarely spend the time and effort necessary to make text-only versions as useful or as robust as the regular versions. They often leave out important information entirely. On a psychological level, text-only versions send a message to people with disabilities: “You can’t come in the front door. Try the back door instead.”
Relegating a class of people to a second-class status may not be the intention behind text-only versions, but sometimes it is the result nevertheless.

False sense of security

A third problem is that text-only sites can give developers a false sense of security. They might think that, with their text-only version, they have finished
their accessibility obligations. They may not think to take additional measures, like captioning their videos, adding illustrations to the main version
where necessary, or even check for missing alt text for images. Accessibility is not something that can be solved once and for all with the implementation of any one solution. Accessibility requires careful planning, and continual vigilance. Having a supposed solution to the problem may lull developers into thinking that they no longer have to engage in keeping accessibility in mind.

Difficult to maintain

On a more practical level, text-only versions can be difficult to maintain. Because they constitute the metaphorical “back door,” designers neglect them.
Updates are not always reflected on the text-only version, and before long, the information is outdated and inaccurate. Some developers have created sophisticated systems to ensure that text-only versions are kept up-to-date with the regular versions. Some keep the content in a database and serve it out through different templates and/or style sheets. Others use the text transcoders of third-party vendors to accomplish the same goal. With these sorts of systems in place, the issues of maintenance may be solved, but they do not negate the other issues with using text-only versions.

When to Use Text-only Versions

Despite all of the arguments against text-only sites, web developers may, on rare occasions, be faced with situations that might call for a text-only solution. Perhaps an interactive multimedia element would be too difficult to make accessible to screen readers. A text-only version may serve as a fallback means of trying to explain what the interactive multimedia element was trying to accomplish. Does this achieve true accessibility? Is the text-only version the equivalent of a complex interactive multimedia element? No, of course not. In these cases, though, something is usually better than nothing, and a text-only version is at least a method of providing something. Some might argue that the multimedia element should either be eliminated or redesigned so that it can be made accessible to screen reader users. They have a point. Where possible, multimedia should be made directly accessible. On the other hand, sometimes these issues are out of the developer’s control—for example, if the multimedia element was created by a third party. Just be careful. Use text-only versions to accommodate certain types of disabilities when necessary, but only when necessary.

Read part one of this series at the link below.

Reproduced from http://www.webaim.org/articles/design/textonly

Ok, you win!! I’ve been converted!!

I’ve been advocating for years the need for providing an alternate document
along with the Portable Document Format (PDF) because all I ever received was
an inaccessible PDF.

I asked nicely over and over again. I tried real hard to be patient. When push
came to shove, I filed a Human Rights complaint. Still to this day your websites
are littered with inaccessible PDFs. I almost gave up!!!

Well, almost.

Read more at
http://www.aoda.ca/?p=447

The ability to access and process electronic information has become one of the most important factors in leading a full and productive life in today’s knowledge-based
society. This makes access to electronic information critical for people with disabilities who are seeking employment and other opportunities.

Significant progress has been made to improve the accessibility of content presented on Web sites, often in HTML format. However, the accessibility of other electronic formats, such as Microsoft Word documents and PDFs, still lags behind and is often added as an afterthought, if at all. Given the enormous volume
of content created daily — often in the form of documents authored by individuals who know little about accessibility — this means far too much material
is inaccessible to far too many people.

Consequently the potential of the Information Age to level the playing field in terms of employment opportunities and to contribute positively to the lives of people with disabilities hasn’t been fully realized. For example, according to the U.S. Census Bureau, the poverty rate for 25- to 64-year-olds was
eight percent, compared to 11 percent for those with a non-severe disability and 26 percent for people with a severe disability.

The Pyramid of Document Accessibility

Accessibility of documents can be implemented at a number of levels, as illustrated by the pyramid above (Follow link below to view image).

At the top of the pyramid are enterprise verification and remediation personnel who are responsible for verifying that content created and disseminated by the enterprise is accessible. This typically involves auditing Web sites and other repositories of information to verify compliance with accessibility legislation, regulations and enterprise policies.

In the middle of the pyramid are quality-assurance and remediation personnel. They are typically responsible for testing documents before they are published and for correcting compliance errors.

At the base of the pyramid are document authors. The authors’ main interest is to create content. They typically are oblivious to accessibility and are rarely aware of what makes a document accessible. There are a number of reasons why applying accessibility at this level can have the greatest impact. Authors know the content well. As a result, they can provide the most effective accessibility information. And authors are far more numerous than quality-assurance or enterprise testing personnel. Making authors responsible for the accessibility of their documents will take accessibility to the grassroots, thereby
increasing the chances that documents are accessible. Also, it’s far less expensive to add accessibility at the author level.

The Problem

Broadly speaking, accessibility of electronic documents remains a highly specialized topic that’s exclusive to accessibility experts. Most electronic documents are created without consideration for accessibility and are then made accessible at a later stage in the life cycle of the document. This is far from optimal
because costs increase exponentially and quality decreases significantly the further accessibility is removed from the authoring stage of the document-management workflow.

The outcomes of such inefficient workflows are several, including the creation of fewer accessible documents due to the significant cost and complexity associated with remediating documents at the later stages of the workflow, and a lower quality of accessibility data within the produced documents.

The Solution

A compelling solution is to make accessibility a part of the authoring process as opposed to a later-stage process that’s often done, if at all, only as an afterthought. Author-level accessibility represents a significant breakthrough that will transform the accessibility of electronic documents by taking
accessibility out of the realm of experts and bringing it into the mainstream.

The Vision

Using effective author-level tools, accessibility can be brought to the grassroots. For example, a university professor who is creating course materials and distributing them to students will easily create fully accessible documents from her or his favorite authoring environment. The professor won’t view this as an added burden but rather
as an integral part of the authoring process, similar to spellchecking. Meanwhile, students with visual impairments will be able to easily read course materials because they will have been created with accessibility built-in by the person most qualified to create this accessibility information. Thus,
the student will not be at a disadvantage compared to sighted students.

In another scenario, a job seeker with a visual impairment will be able to read job postings produced as PDF documents and fill out an online application form because the postings and forms will have been built with accessibility integrated into the documents and forms by their authors. This will enable job seekers to more effectively locate a suitable job and apply for it.

Effective Author-Level Tools

Central to achieving this vision are software tools that integrate into the authoring environment and ensure documents are made accessible by the author. In order for such tools to be effective, they must meet criteria.

• They should be integrated into the authoring environment so that the author does not have to exit the authoring application to run the accessibility tool.
• They should inherently verify documents against a well-defined standard, such as Section 508 or W3C WCAG 2.0. Once the tool finishes the verification and assuming the author followed instructions, the document should be compliant with the specific standard.
• They should provide the ability to both verify and fix compliance problems.
• They should impose a minimal burden on authors in terms of their knowledge of accessibility or the amount of work that’s required to make a document accessible.
• They should use basic, nontechnical language and provide clear explanations and examples. It cannot be assumed that document authors understand technology or have more than a basic level of familiarity with their tools.

Accessible and Nonaccessible Formats

It should be noted that for tools to support a specific standard for a given document format, the document format itself must support the accessibility structures that are required by the standard. For example, formats like HTML 4.0 or PDF 1.8 support all basic structures required for Section 508 and WCAG 2.0. The Microsoft Word 2007 format, on the other hand, does not; for example, it doesn’t provide support for row headers.

The degree of accessibility of a given format should be differentiated from how difficult it is to make the format accessible. For example and assuming tools are not used, while it may be significantly harder to add accessibility features to a PDF document than a Word document, a PDF document containing tables can be made accessible while a Word 2007 document cannot. PDF supports all the accessibility structures for tables while MS Word 2007 does not.

Conclusion

Author-level tools can bring document accessibility to the grassroots, but they have to meet a several criteria related to how easy they are to use and to how fully they support specific standards. Effective author-level tools make it possible to implement more optimal workflows that can enable content authors to create accessible content from the outset.

Deborah Kaplan is the director of the Accessible Technology Initiative at the California State University Chancellor’s Office. She has several decades of experience in advocating for accessible technology and its implementation. She is the former executive director of the World Institute on Disability and a consultant to technology firms. As the director of the CSU’s Accessible Technology Initiative, she oversees a comprehensive effort to implement accessible
technology in the largest four-year higher-education system in the U.S. She has a law degree from University of California, Berkeley and a bachelor’s degree from University of California, Santa Cruz.

Monir ElRayes is founder, president and CEO of NetCentric Technologies, a company that provides document-compliance solutions designed to enable government, educational institutions and corporations to ensure the accessibility of electronic documents and their compliance with a variety of standards. ElRayes
holds a master of engineering (electrical) degree from Cornell University and a bachelor of science degree (electrical engineering) from the University of Iowa. 

Reproduced from http://www.govtech.com/gt/articles/752442

Alternate text is not meant to be used as a tool tip, or more specifically, to provide additional information about an image. The title attribute, on the
other hand, is meant to provide additional information about an element. That information is displayed as a tooltip by most graphical browsers, though
manufacturers are free to render title text in other ways.

Read more at
http://www.456bereastreet.com/archive/200412/the_alt_and_title_attributes/