principle-4-robust

Posted on April 30, 2019 Posted by Victoria Brooks

principle-4-robust

principle-4-robust

Posted on April 30, 2019 Posted by Victoria Brooks

principle-2-operable

Guideline 2.1: Don’t forget users without a pointer


Make all functionality available from a keyboard

When a functionality can be achieved using only the keyboard, other input devices can be used. But, if you use only a mouse or a speech input, assistive technologies will find it difficult to operate it.

Obviously, you can use another input devices to complement the keyboard, and even you are encouraged to do it, but don’t forget that every feature must be operable by a keyboard input.

Read more


Guideline 2.2: Don’t hurry up anyone


Provide users enough time to read and use content.

Imagine you are reading a webpage and, in the middle of that proccess, the page reloads and changes, so you can not finish the reading of the formerly page. Everybody needs different time to complete tasks, and this time is usually higher on the elderly and users with disabilities.

So this guideline is about eliminating time constraints or providing users enough additional time to allow them to complete their tasks.

Read more


Guideline 2.3: Be careful with flashing visual content


Do not design content in a way that is known to cause seizures.

Three-flash-in-a-second is the lower rate recommended to show flash content for people who suffer from seizures due to photosensitivity, specially for red lights. But still there are more sensitive people that react to lower rates, so the recommendation is to eliminate this type of visual content.
What is the difference between “blinking” and “fashing”?

blinking
content that distracts, and can be used for a short time as long as it stops or can be stopped by the user. If blinking occurs faster than 3 per second, it should be considered a flash.
flashing
content faster than 3 per second, and large and bright enough to cause a seizure The chance to turn the flash off is not an option since the seizure could occur faster than most users could turn it off.

How do you know if your content is flashing or blinking? Try the Photosensitive Epilepsy Analysis Tool.

In order to not interfere with other content of the webpage, these criteria applies for the whole page.

Read more


Guideline 2.4: Focus on Information Architecture


Provide ways to help users navigate, find content, and determine where they are

Finding the content and keeping track of our location are usually difficult tasks for people with disabilities, especially for those who use screen reader or cognitive disabilities. So these criteria are made for them.

Best practices

  • Limit the number of links per page
  • Provide mechanisms to navigate to different sections of the content of a Web page
  • Make links visually distinct

Read more


principle-2-operable

Posted on April 30, 2019 Posted by Victoria Brooks

principle-1-perceivable

Guideline 1.1: Provide text alternatives


Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language.

Text can be rendered in a visual, oral or tactile way. Even by any combination of them. So text information can be presented and manipulated in whatever form best meets the user needs. For example, a blind person can understand a picture if her browsers reads aloud the text alternative. Or a deaf person can understand an audio file if there is a text alternative on the screen.

Read more


Guideline 1.2: Time-based Media


Provide alternatives for time-based media

You can use this guideline both for time-based media and synchronized media (with another format and/or time-based interactive components), including:

  • only audio
  • only video
  • audio and video combined
  • audio and/or video combined with interaction

Best practices

  • Prerecorded audio: Provide an alternative that presents equivalent information for prerecorded audio-only content.
  • Prerecorded video: Provide either an alternative for time-based media or an audio track to present equivalent information for prerecorded video-only content.
  • Prerecorded synchronized media: Provide an audio description or media alternative.
  • Prerecorded audio in synchronized media: Provide captions, and if possible, also sign language interpretation.
  • Live audio content in synchronized media (Live): provide captions.
  • Prerecorded video content in synchronized media (): Provide an audio description.
  • Embed interactive elements (for example links) in the alternative content where appropiate.

Read more


Guideline 1.3: Present content in different ways


Create content that can be presented in different ways (for example simpler layout) without losing information or structure.

Your website audience has very different needs and preferences, so ensure that your content is available in a way that can be perceived by all users in different ways (visually, audibly, tactilely etc.).

If there is embedded information in a way that the structure and information cannot be rendered by the assistive technology, then it cannot be rendered in other formats as needed by the user. (e.g. text in an image).

WCAG 2 refers to structure as the way the parts of a Web page are organized in relation to each other; and the way a collection of Web pages is organized; and presentation as rendering of the content in a form that can be perceived by users.

Read more


Guideline 1.4: Separate background from foreground


Make it easier for users to see and hear content including separating foreground from background.

This guideline is about making the default presentation as easy to perceive as possible to people with disabilities: it’s about contrast, not only the ‘colors’ for visual content, but also for the ‘voices’ on audio content.

Best practices

  • Use readable fonts.
  • Text in images should be at least 14 points and has good contrast.
  • Links and controls must be highlighted when they receive keyboard focus.

Read more


principle-1-perceivable

Posted on April 30, 2019 Posted by Victoria Brooks

the-way-we-use-the-technology-determines-its-accessibility-support

The way we use the technology determines its accessibility support


Remember these categorical clauses? ‘Don’t do your web in Flash because it will not be accessible’ or ‘Avoid PDF, because a blind person won’t be capable to read it’. Industries participant in the redaction of the new guidelines have adopted a tougher line protecting their products from legal barriers. So that’s why there is no mention to which technology is accessible and which not, because it depends on the way that they are used. E.G. You can use plain, strict XHTML but it is not well formatted, it wont be accessible. But if you create your website with Flash and all the accessibility features on, it will be accessible.

That undefined situation makes that the W3C stands on a neutral position about technology, but not about its use.

Problems attached to this neutrality are:

  • they cannot specify which or how much support there must be for a particular use of a Web technology to be classified as accessibility supported
  • you can use web technologies in an un-accessible way, but you must provide an accessible alternative version
  • You can use a technology in an accessibility support way, but it don’t imply that all uses of that technology or all the versions of that technology are supported

Remember that we can only audit complete webpages, not technologies.

Technology Uses List

Unfortunately, we must trust on anyone (individuals, companies, universities, vendors…) who document accessibility supported uses. The only requisite is to meet the definition of accessibility support. In any case, an individual author won’t be able to test all the possible uses, so there will exist scattered documentation all over the web. And even worst, nobody will be capable to test all that tests. Can you imagine the lack of security this involves? The only thing that WAI warns is that

The Working Group anticipates that only documents that provide accurate information and benefit both authors and users will achieve market recognition in the long term.

If you want to create your own list, follow the instructions provided in Documenting Accessibility Support for Uses of a Web Technology

More info


the-way-we-use-the-technology-determines-its-accessibility-support

Posted on April 30, 2019 Posted by Victoria Brooks

how-can-i-determine-if-a-web-technology-is-accessibility-supported

How can I determine if a web technology is ‘accessibility supported’?


Let’s assume that nobody knows which technologies are and aren’t accessibility supported. Now what? Well, the WAI has tried to bring a definition, not very clear, but a definition after all:

a Web content technology is “accessibility supported” when users’ assistive technologies will work with the Web technologies AND when the accessibility features of mainstream technologies will work with the technology.

So if you want to decide by yourself if a web content technology is accessibility supported, you must check that:

  • The Web content technology is supported by users agents, including assistive technology, in the same human language.
  • Users can get accessibility-supported user agents to support that content. This can be achieved by one of these:
    • it’is supported natively in widely-distributed user agents or by a widely-distributed plug-in that are also accessibility supported (such as HTML and CSS);
    • You can control which user agents do your users use to access to your content, eg, an intranet. Obviously, the user agent required and used is also accessibility supported;
    • You can download or buy the user agent in an easy way. This process will not discriminate against people with or without disabilities.

In the next post I will introduce the importance of the use of technologies because depending on the way we use them, they become accessibility supported or not. Weird, isn’t it?

More info


how-can-i-determine-if-a-web-technology-is-accessibility-supported

Posted on April 30, 2019 Posted by Victoria Brooks

which-technologies-are-accessibility-supported

Which technologies are ‘accessibility supported’?


At this point you will probably wonder which web technologies are accessibility supported and which are not. And the answer is… nobody knows, not even the WAI! Now, the consultancy best phrase: ‘it depends’. How is this possible after 5 years of  WCAG 2 developing? Well, some reasons for this vagueness.

  • How many user agents (including assistive technologies) must support a web technology to be considered as ‘accessibility supported’?
  • What if a web technology is supported in one environment and not in other? You may only need a particular user agent, or a combination of many?
  • Which languages and dialects must support the user agent to support web technologies? E.g. Screen readers may not understand ‘Chinese’  content at all.
  • Backwards compatibility? E.g. Imagine that 3D web navigation technologies arise. Old computers and software won’t be capable to show that content. But that is not an obstacle to consider that this 3D technology (maybe) is accessibility supported.
  • Unless you provide all your users with the proper user agent to display your content, there must be different options for the users to access to that content, particularly if they cannot afford assistive technology. Usually assistive technology is expensive and not everyone can afford them. Beside, free or lowcost assistive technology don’t have the same performance as expensive equipment.

So you can deduct that it is not easy to define which web technologies are accessibility supported and which are not. The WAI understand this problem and trust the community to select them. Yes, each company, government or  association can evaluate. So prepare yourself for a bunch of resolutions. As the WCAG 2 says:

this lack of generally available yet robust assistive technologies is a problem that affects users, technology developers and authors negatively.

In the next post we will explain how to reduce this uncertainty.

More info


which-technologies-are-accessibility-supported

Posted on April 30, 2019 Posted by Victoria Brooks

whats-accessibility-support

What’s ‘Accessibility Support’?


The basic difference between a technology that is accessibility supported and a technology that is relied upon. But the scope of both terms is wider and more complex that a single-line definition.

WCAG 2 has tried to overcome a big problem that WCAG 1 has: technology dependence. WCAG 1 checkpoints included many times the phrase “Until user agents allow…” or “Until user agents can…”. But the WAI never updated the official document “User agent support for technology“. So we had a nice dead end.

WAI has tried to overcome this situation making the WCAG 2 neutral from technology. But it has created another problem. As Joe Clark’s posted on A list apart “To hell with WCAG 2“:

WCAG 1 was strongly HTML-specific. Everybody recognized that as a problem in an age when formats that blind people love to hate, like PDF and Flash, are slowly becoming accessible. So WCAG 2 had to be technology-neutral.
But in so doing, it imagined a parallel universe in which the vast majority of web content ceased to be plain-Jane HTML, CSS, and JavaScript.

It envisioned a world in which lots and lots of Flash, PDF, and other, as-yet-uninvented formats were available and intended to be accessible. To accommodate this dreamworld, WCAG 2 was written and rewritten and rerewritten to apply to everything. Along the way, it lost the ability to apply to the real things real developers work on every day—plain-Jane HTML, CSS, and JavaScript.

I will try to explain the concept “Accessibility support by 3 examples”:

  • If you include a movie on your page, how do you include the subtitles?
  • If you include an image, how do you include the alternate text?
  • If you include a custom control (e.g. a flash interactive movie), how do you include an alternative content?

The key is to include the alternative version in a way that user agents including assistive technologies can understand and use. That’s “Accessibility Supported”.

So, what’s the big deal on it? Well, WCAG 2 has thought even on technologies that are not already invented.

“Accessibility Supported” means

  • The new technologies are designed in a way that user agents including assistive technologies could access all the information they need to present the content to the user.
  • the user agents and assistive technologies may need to be redesigned or modified to be able to actually work with these new technologies.

So, if the two previous points are true, the technology will work with user agents and assistive technologies.

More info


whats-accessibility-support

Posted on April 30, 2019 Posted by Victoria Brooks

accessibility-support

How can I determine if a web technology is ‘accessibility supported’?


Let’s assume that nobody knows which technologies are and aren’t accessibility supported. Now what? Well, the WAI has tried to bring a definition, not very clear, but a definition after all:

a Web content technology is “accessibility supported” when users’ assistive technologies will work with the Web technologies AND when the accessibility features of mainstream technologies will work with the technology.

Read more


The way we use the technology determines its accessibility support


Remember these categorical clauses? ‘Don’t do your web in Flash because it will not be accessible’ or ‘Avoid PDF, because a blind person won’t be capable to read it’. Industries participant in the redaction of the new guidelines have adopted a tougher line protecting their products from legal barriers. So that’s why there is no mention to which technology is accessible and which not, because it depends on the way that they are used. E.G. You can use plain, strict XHTML but it is not well formatted, it wont be accessible. But if you create your website with Flash and all the accessibility features on, it will be accessible.

Read more


accessibility-support

Posted on April 30, 2019 Posted by Victoria Brooks

tools

Evaluation tools


Tools can reduce the time and effort required to carry out evaluations, as they can automate tests or assist reviewers in the manual evaluation. However, we have some bad news:

  • The WCAG 2 does not provide an official tool to check the websites.
  • There is not any fully automatable, stand-alone evaluation tool, even non-official, which can perform the whole audit.
  • The W3C does not promote nor endorse any tool.
  • Tools’ results may be false or misleading, so an expert review has to embrace or dismiss them.

Although the W3C has collected a wide set of tools, they are pretty outdated. The W3C has updated its tools list, where you can filter by guidelines version, language and how the tool assists the evaluator (generating reports of evaluation results, providing step-by-step evaluation guidance, displaying information within web pages, or modifying the presentation of web pages).

Here is our selection of evaluation tools:

General Automatic Validations
Total Validator
Wave
Code validation
Mark up
Cascade Style Sheets
Mobile Friendlyness
Color
Luminance contrast
Find combinations of colors
Color Blind Simulation
PEAT – Photosensitive Epilepsy Analysis Tool
Sound
Audio contrast
Asssisting in the manual evaluation
PISTA (in Spanish): Install the program and then add the WCAG 2 module.
Accessibility Toolbar by Paciello Group
Link checker

More info


tools

Posted on April 30, 2019 Posted by Victoria Brooks

wcag-20-conformance

Webpages conformance levels


So, once you have tested the success criteria, you can state the conformance of your webpage into 3 levels:

  • Level Single-A (A): your webpage satisfies all the Single-A (A) success criteria.
  • Level Double-A (AA): your webpage satisfies all the Single-A (A) and Double-A (AA) success criteria.
  • Level Triple-A (AAA): your webpage satisfies all the Single-A (A), Double-A (AA) and Triple-A (AAA) success criteria.

Read more