<Jan> A mechanism for encoding instructions to be rendered, played or executed by user agents. Web Content technologies may include markup languages, data formats, or programming languages that authors may use alone or in combination to create end-user experiences that range from static Web pages to multimedia presentations to dynamic Web applications. Some common examples of Web content technologies in

<Jan> clude HTML, CSS, SVG, PNG, PDF, Flash, and JavaScript. An accessible technology is a technology that may be used in a way that is "accessibility supported" (For more information on "accessibility supported", see WCAG 2.0).

<jeanne> http://www.w3.org/2002/09/wbs/35520/AUWG-F2F-20090615/results

<jeanne> http://www.w3.org/2002/09/wbs/35520/AUWG-F2F-20090615/

<Jan> Scribe: Andrew

Guideline B.1.1 Support Web content technologies....

<Jan> http://lists.w3.org/Archives/Public/w3c-wai-au/2009AprJun/0053.html

JR: Requirement around the tool choosing technologies that are "accessibility supported"
... Quite a subtle term that comes from WCAG

<Jan> Rationale: The production of *accessible Web content* is only possible

<Jan> if *authoring tools* make use of *Web content technologies* that can be

<Jan> used in ways that are *accessibility supported*.

<Jan> B.1.1.1 Automatic Technology Selection: If *Web content technologies*

<Jan> are automatically selected by the *authoring tool* (e.g., for *automatic

<Jan> content generation*, as the default technology for *author-generated

<Jan> content*), then the *Web content technologies* can be used in ways that

<Jan> are *accessibility supported*. (Level A)

<Jan> B.1.1.2 Author Choice of Technologies: If *authors* are provided with a

<Jan> choice of *Web content technology* options, any *Web content technology*

<Jan> options that can be used in ways that are *accessibility supported* are

<Jan> *at least as prominent* as any options that cannot. (Level A)

<Jan> B.1.1.3 Technology Warning: If the *authoring tool* can *recognize* that

<Jan> *authors* have chosen to use a *Web content technology* that may not be

<Jan> able to be be used in ways that are *accessibility supported*, then the

<Jan> *authoring tool* notifies the *authors* that this may result in *Web content

<Jan> accessibility problems* in the output. (Level AA)

JR: Next piece is quite large but thought about it a lot

<Greg> +1 for using the same definition as WCAG

JR: Thinking about bringing across the "accessibility supported" definition from WCAG

<Jan> NEW DEF'N IN THE GLOSSARY:

<Jan> accessibility supported [adapted from WCAG 2.0]

<Jan> Supported by *end users'* *assistive technologies* as well as the

<Jan> accessibility features in browsers and other *user agents*. To qualify

<Jan> as an accessibility-supported use of a *Web content technology* (or

<Jan> feature of a technology), both 1 and 2 must be satisfied for the *Web

<Jan> content technology* (or feature):

<Jan> 1. The way that the *Web content technology* is used must be supported

<Jan> by *end users'* *assistive technology* (AT). This means that the way

<Jan> that the *Web content technology* is used has been tested for

<Jan> interoperability with *end users'* *assistive technology* in the *human

<Jan> language(s)* of the *Web content*,

<Jan> AND

<Jan> 2. The *Web content technology* must have accessibility supported *user

<Jan> agents* that are available to *end users*. This means that at least one

<Jan> of the following four statements is true:

<Jan> a. The *Web content technology* is supported natively in

<Jan> widely-distributed *user agents* that are also accessibility supported

<Jan> (such as HTML and CSS);

<Jan> OR

<Jan> b. The *Web content technology* is supported in a widely-distributed

<Jan> plug-in that is also accessibility supported;

<Jan> OR

<Jan> c. The *Web content* is available in a closed environment, such as a

<Jan> university or corporate network, where the *user agent* required by the

<Jan> *Web content technology* and used by the organization is also

<Jan> accessibility supported;

<Jan> OR

<Jan> d. The *user agent(s)* that support the *Web content technology* are

<Jan> accessibility supported and are available for download or purchase in a

<Jan> way that:

<Jan> - does not cost a person with a disability any more than a person

<Jan> without a disability and

<Jan> - is as easy to find and obtain for a person with a disability as it

<Jan> is for a person without disabilities.

<Jan> Notes:

<Jan> - The AUWG, WCAG Working group and the W3C do not specify which or how

<Jan> much support by assistive technologies there must be for a particular

<Jan> use of a *Web content technology* in order for it to be classified as

<Jan> accessibility supported. (See “Understanding Accessibility Support” in

<Jan> “Understanding WCAG 2.0” for more details).

<Jan> - See also the *conformance profile* requirements for documenting

<Jan> “accessibility supported”.

JR: Conformance claims are optional in WCAG

<Jan> 5(b) A list of the *Web content technologies* (including version

<Jan> numbers) produced by the *authoring tool* that the Claimant is

<Jan> *including* in the conformance claim.

<Jan> - The list must include any *Web content technologies* identified in

<Jan> Guideline B.1 as being able to be used in ways that are *accessibility

JS: Like the idea of mirroring WCAG's process. Complicated process so we risk adding more confusion if we don't follow WCAGs lead.

<Jan> supported*.

<Jan> - For each *Web content technology*, specify the conditions under which

<Jan> the *Web content technology* can be used in ways that are

<Jan> *accessibility supported* (e.g., specify known *assistive technology*

<Jan> support, *user agent* support, plug-in support, in what *human

<Jan> languages*, in what closed environments, etc.). NOTE: It is the

<Jan> responsibility of *authors* to decide whether these conditions for

<Jan> *accessibility supported* are actually applicable in the context of the

<Jan> *authors'* own circumstances (e.g., the *human language* of their *Web

<Jan> content*, whether they develop in open vs. closed environment, etc.)

<Jan> 5(c [was d]) A list of the *Web content technologies* produced by the

<Jan> the *authoring tool* that the Claimant is *excluding* from the

<Jan> conformance claim. *Web content Technologies* may only be excluded that

<Jan> are not automatically selected by the *authoring tool* (See Success

<Jan> Criterion B.1.1).

AM: My concern is the people who are making the tools don't know all the "technical ways" web content technologies can be made accessible

JT: In an ideal world there would be a guide to accessible web content technologies for tool developers to refer to

<Jan> Accessibility Support Statements

<Jan> Examples of ways in which a conformance claim might document its accessibility support include:

<Jan> 1.This conformance claim meets the accessibility support requirement based on testing content in language(s) of the content with User Agents A, B, and C, and Assistive Technologies X, Y, and Z. This means that we were able to pass all of the success criteria for level A of WCAG 2.0 using these products.

<Jan> 2.This conformance claim meets the accessibility support requirement for the language(s) of the content based on the use of techniques and user agent notes documented in Techniques for WCAG 2.0. It is also based on the accessibility support documentation for the technologies (that we relied upon for conformance), which is available in " XYZ Organization's Documentation of Accessibility Support."

<Jan> 3.This conformance claim meets the accessibility support requirement for the language(s) of the content based on the use of technology Z as documented in "Technology Z accessibility supported techniques for WCAG 2.0."

<Jan> 4.This conformance claim meets the accessibility support requirement for the language of the content based on the use of Accessibility Guidelines for Technology A and Accessibility Guidelines for Technology B. User agent and assistive technology support information can be found in "Product XYZ Accessibility Support Requirements", which are documented in these guidelines.

JR: How can you tell what is a more accessible choice?

GR: If you choose to produce Flash for example, the tool should facilitate creating accessible Flash
... This shouldn't become a debate about one format over another

JR: We used to have the "accessibility benchmark" concept
... All formats can be used in an accessible or inaccessible way
... Even if the tools are capable of producing accessible output

<Greg> Action GP Intermediate and evaluating accessibility of formats w/o pitting them against each other

<trackbot> Created ACTION-153 - Intermediate and evaluating accessibility of formats w/o pitting them against each other [on Greg Pisocky - due 2009-06-15].

<Jan> ACTION: GP to writeup applicability ideas around "intermediate formats" [recorded in http://www.w3.org/2009/06/08-au-minutes.html#action01]

<trackbot> Created ACTION-154 - Writeup applicability ideas around "intermediate formats" [on Greg Pisocky - due 2009-06-15].

<Jan> ACTION: JR to Take another look at simplifying B.1 and the formats issue [recorded in http://www.w3.org/2009/06/08-au-minutes.html#action02]

<trackbot> Created ACTION-155 - Take another look at simplifying B.1 and the formats issue [on Jan Richards - due 2009-06-15].

This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found Scribe: Andrew
Inferring ScribeNick: Andrew
Default Present: +0208123aaaa, Jeanne, AnnM, Jan, Jutta, Greg_Pisocky, +1.970.349.aabb, SueannN, AndrewR, +2
Present: +0208123aaaa Jeanne AnnM Jan Jutta Greg_Pisocky +1.970.349.aabb SueannN AndrewR +2
Regrets: Roberto_S. Tim_B.
Agenda: http://lists.w3.org/Archives/Public/w3c-wai-au/2009AprJun/0051.html
Got date from IRC log name: 08 Jun 2009
Guessing minutes URL: http://www.w3.org/2009/06/08-au-minutes.html
People with action items: gp jr