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

Posted on January 30, 2020 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 January 30, 2020 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 January 30, 2020 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 January 30, 2020 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 January 30, 2020 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 January 30, 2020 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


wcag-20-conformance

Posted on January 30, 2020 Posted by Victoria Brooks

the-evaluation-procedure

The evaluation procedure


The core procedure provides five sequential steps, and each step has its own sub-steps.

  1. Define the evaluation scope:
    After a brief exploration of the site and conversations with the responsible stakeholders, we define:

    1. The scope of the website, or which pages are going to be evaluated.
    2. The conformance target (“A”, “AA”, or “AAA”)
    3. An accessibility support baseline, or the minimum set of combinations of user agents (operating systems, web browsers, assistive technologies…) that the website is expected to work with.
    4. Other optional additional evaluation requirements
  2. Explore the target website:
    Here we identify relevant pages of the site, and maybe we change the evaluation scope previously defined. This exploration includes the identification of:

    1. Common web pages
    2. Essential functionalities
    3. Web page types and states
    4. Web technologies relied upon
    5. Other relevant web pages
  3. Select a representative sample:
    Depending on the size, the age, the complexity and consistency of the site, the adherence to development processes, the required level of confidence and the availability of prior evaluation findings, we will include:

    1. A structured sample
    2. A randomly selected sample
    3. Complete processes
  4. Audit the selected sample:
    This is the moment when we check all of the web pages and web page states selected in the third step with the Techniques procedures. Precisely we check:

    1. All initial web pages
    2. All complete processes
    3. And compare structured and random samples
  5. Report the Evaluation Findings:
    Finally, it is time to document if the pages have passed or not the tests, where we provide

    1. The outcomes of each step, with the name of the evaluator, the date, the scope, the exploration, the representative sample and the sample audited.
    2. Optionally, the record of the evaluation specifications, that is, an archive of the web pages and states, evaluation tools, browsers…
    3. Optionally, an evaluation statement describing the outcomes of the conformance evaluation (not a conformance claim, but similar).
    4. Optionally, an aggregated score, to understand the evolution in quantitative data. Although the WCAG 2 does not provide scoring metrics, the W3C is researching on it.
    5. Optionally, machine-readable reports in the Evaluation and Report Language (EARL)

More info


the-evaluation-procedure

Posted on January 27, 2020 Posted by Victoria Brooks

examples-of-conformance-claims

Examples of conformance claims

The conformance claim has several components, divided into 3 parts:

 

1. What pages conforms and the level (Required)

The whole site conforms
On 14 October 2009, all Web pages at http://www.mydomain.com conform to Web Content Accessibility Guidelines 2.0 at http://www.w3.org/TR/2008/REC-WCAG20-20081211/. Level A conformance.
Some parts of the site conforms: using regular expressions
On 14 October 2009, all Web pages at http://www.mydomain.com/(products|contact)/.* conform to Web Content Accessibility Guidelines 2.0 at http://www.w3.org/TR/2008/REC-WCAG20-20081211/. Level AA conformance.
Some parts of the site conforms: using boolean logic
On 14 October 2009, the following web pages conform to Web Content Accessibility Guidelines 2.0 at http://www.w3.org/TR/2008/REC-WCAG20-20081211/. Level AA conformance.

  • (http://www.mydomain.com/
  • AND http://subdomain1.mydomain.com/ )
  • AND NOT (http://subdomain2.mydomain.com/
  • OR http://subdomain3.mydomain.com/)
Only one page
On 14 October 2009, the web`page “Contact” at http://www.mydomain.com/contact.html conforms to Web Content Accessibility Guidelines 2.0 at http://www.w3.org/TR/2008/REC-WCAG20-20081211/. Level A conformance.

2. What used technologies are “accessibility supported” (Required)

To put it short, a technology is accessibility supported if that technology will work with user agents and assistive technologies and a technology is relied upon if the content would not conform if that technology is turned off or is not supported.

Listed on a page
The documented set of accessibility-supported content technologies relied upon for this claim is listed at http://www.mydomain.com/accessibility/technologies.html
Listed on the claim
The technologies that this content relies upon is: XHTML 1.0 Strict, CSS 2.0 and JavaScript 1.2.
Subset of a list on a page
The documented set of accessibility-supported content technologies relied upon for this claim includes XHTML 1.0 and SMIL from “January 2009 list” at http://www.mydomain.com/accessibility/technologies.html#january2009.

3. Other components (Optional)

Going beyond the level
The following additional Success Criteria have also been met: 1.1.2, 1.2.5, and 1.4.3.
Technologies used (both relied and not relied)
  • The technologies that this content relies upon is: XHTML 1.0 (Strict), and Real Video.
  • The technologies that this content uses but does not rely upon are: JavaScript 1.2, CSS2.
User agents you have tested with
  • The user agents, including assistive technologies, that this content has been tested with can be found at http://www.mydomain.com/accessibility/test-technologies.html
  • This content was tested using the following user agents and assistive technologies: Firefox 1.5 on Windows Vista with Screenreader X 4.0, Firefox 1.5 on Windows XP SP 2 with Screenreader X 3.5, IE 6.0 on Windows 2000 SP4 with Screenreader Y 5.0, IE 6.0 on Windows 2000 SP4 with Screenreader Z 2.0, and Firefox 1.5 on Windows XP SP2 with Screenreader X 4.0, Safari 2.0 with OS X 10.4.

More info

examples-of-conformance-claims

Posted on January 27, 2020 Posted by Victoria Brooks

introduction-to-accessibility-evaluation

Introduction to Accessibility Evaluation


The WCAG 1.0 did not have any official way to audit the accessibility of the websites. This led to the creation of different non-official evaluation methodologies. For example, the European Union founded the Unified Web Evaluation Methodology or UWEM, which was never adapted to the new WCAG 2.

This time the W3C has not forgot this issue and have developed the Website Accessibility Conformance Evaluation Methodology or WCAG-EM, albeit six years after the publication of the WCAG 2. This document is still a “Note”, not an official “Recommendation”, but we can consider it a stable reference.

If you have ever used the UWEM, they were divided into two documents: one with the core procedure, and another with the tests you should perform to verify each guideline. The WCAG-EM only provides the core procedure. We will explain it in the next post ‘The evaluation procedure’.

To verify each succes criterion, you have to follow the Techniques documentation. For example, to test if a webpage conforms to the succes criteria 1.2.3, 1.2.5 and 1.2.7 (all related to “Audio-descriptions”), you have to follow the procedure of the technique G8: Providing a movie with extended audio descriptions. There are 591 techniques and procedures to take, so have a seat while you are evaluating a website, and it is absolutly out of the scope of this tutorial to explain each procedure.

Finally, bear in mind that with the WCAG-EM we are only evaluating a selection of pages of your website, so be careful what you state in your conformance claim. Remember that the WCAG 2 considers a website as a whole: full pages, processes, functionalities…

More info


introduction-to-accessibility-evaluation

Posted on December 27, 2019 Posted by Victoria Brooks

how-to-tell-everybody-that-your-webpage-is-ok

How to tell everybody that your webpage is ok


Once you have tested your webpages, you want to tell everyone that you have cared about accessibility. In WCAG 1.0 you had the fancy logos, but they had a great problem: everybody could use them despite of being accessible or not.

Nowadays, the W3C is unable to verify each website that uses the logo, so the WAI tries to fix this problem using a conformance claim with the new logos:

Single-A
Level A conformance, W3C WAI Web Content Accessibility Guidelines 2.0

<a href="http://www.w3.org/WAI/WCAG2A-Conformance" title="Explanation of WCAG 2.0 Level A Conformance"><img height="32" width="88" src="http://www.w3.org/WAI/wcag2A" alt="Level A conformance, W3C WAI Web Content Accessibility Guidelines 2.0"></a>

Double-A
Level Double-A conformance, W3C WAI Web Content Accessibility Guidelines 2.0

<a href="http://www.w3.org/WAI/WCAG2AA-Conformance" title="Explanation of WCAG 2.0 Level Double-A Conformance"><img height="32" width="88" src="http://www.w3.org/WAI/wcag2AA" alt="Level Double-A conformance, W3C WAI Web Content Accessibility Guidelines 2.0"></a>

Triple-A
Level Triple-A conformance, W3C WAI Web Content Accessibility Guidelines 2.0


<a href="http://www.w3.org/WAI/WCAG2AAA-Conformance"
title="Explanation of WCAG 2.0 Level Triple-A Conformance">
<img height="32" width="88" src="http://www.w3.org/WAI/wcag2AAA"
alt="Level Triple-A conformance, W3C WAI Web Content Accessibility Guidelines 2.0">
</a>

Both conformance icons and claims refer to a single webpage, unless the webmaster includes an explicit scope information explaining which pages are covered by the claim and the icon. The pages can be a series of pages (e.g. a checkout) or multiple related webpages (e.g. a subdomain).

If you are really cool, you can conform to WCAG 2.0 without making any claim, because conformance claims are not required. Just be good at your job!

More info