<Greg> Jutta is still here!

<Reed> scribe:reed

RS: Change B.2.4.2 to reflect capabilities of the product and not force editing of all object types

JR: we already have modify directly above, do we need to repeat?
... What does 2.4.2 add?
... 2 scenarios. Author is putting it in, or already exists and author is trying to modify or maintain
... I want to flag B.2.4.2 as problematic in some respect
... Let's look at some of the wording I typed up last night

<jeanne> can we close issue 84? http://www.w3.org/WAI/AU/tracker/issues/84

Jan's proposal from last evening

<jeanne> http://lists.w3.org/Archives/Public/w3c-wai-au/2008JulSep/0050.html

JR: Tool specifies what it authors and what it can reference
... E.g., it can reference flash, but doesn't have to get into flash accessibility

<jeanne> Cynthiha: COnforming alternate versions is a preferred method according to WCAG. As a Microsoft employee, I recognize that it is difficult to implement practically.

<jeanne> Reed: I should only allow conforming alternatives when the technology doesn't allow you to edit it.

<jeanne> Cynthia: Conforming alternatives should only be things like widgets or really complex scripted page.

<jeanne> Reed: Should you try to do it, yes? Should you be required to do it? No.

Jutta: previously we had talked about drawing a cirlce around external tool (repair or checking), part of the objections regarding checking and repaid would be alleviated by including a conformance claim

JR: you can make sure the widget is accessible, provide labeling, infrastrucuture, etc but you only lose control once the newsfeed is there.

CS: But you can provide an accessible API
... If you are using an API that has that data, you should be expected to pass that through
... choosing the API, is that a tool choice?

JR: it's the widget that gets feed, turns into...

CS: If you want an accessible AD widget, you need iframe with need, script accessible, and you need ads to have alt text

JS: Does this change impact/relevance of applicability section?

<jeanne> Issue raised by Cynthia about Part B - pushing feeds to provide accessible API

JR: I am going to drop these in but with editor notes

<jeanne> Issue: raised by Cynthia about Part B - pushing feeds to provide accessible API

<trackbot> Created ISSUE-154 - Raised by Cynthia about Part B - pushing feeds to provide accessible API ; please complete additional details at http://www.w3.org/WAI/AU/tracker/issues/154/edit .

JR: focusing B1.1
... if the technologies you have chosen to benchmark...those need to be the formats if you are automatically selecting
... you should provide prominence to ones with benchmark documents
... consider providing benchmark documents for technology that you authoring tool already uses by default or pominently offers as option

CS: why and how does that help make my product accessible?

JR: Since the way in which content can be made accessible in the technologies your tools is outputting will be useful in guiding decisions about...
... authroign support

JS: I would your tool outputs rather than is outputting

JR: specify instead of understand?

<jeanne> Reed: What if I don't have an authoring tool, and I'm starting to build one? Can this guide my decisions on what technologies to consider?

CS: shouldn't we hope accessible formats are chosen by new devs?

<AnnM> got knocked off the call. back in a min.

<jeanne> Reed: Where possbile, use existing benchmarks to make decisions on what technologies should be used.

JS: is there a store of benchmark documetns?

JR: nope.
... need to convince, all we are doing is letting a company specify the accessibility

JS: for authroign tools, this will mostly be vendors

JR: would you create your own?

JS: waht are we trying to get?

JR: reed goes back to where we were, you may already know what you are doing or you may be fuzzy around what should I use?
... and then consider fully benchmarked, give it consideration as output

JS: strong accessibility considerations
... need some grammar work here

CS: i would break it into 2 sentences

JR: I am sugesting 2 that were similar before and they should both be level a
... this is maybe a wcag thing, how do you decide

CS: there are cases with scenarios where you can make choices

JR: if we give up benchmarks at this point, all of section b is done at this point
... we need a way of weighing formats against each other

CS: but for existing tools that's a reasonable approach, for a new tool how do I get help from this document?

JS: let's take Dojo, how would we go from here

JR: are going to pull that in and say how do we compare formats?

CS: svg is a great format but is that what you should choose

JR: this format can't deal with these things

CS: all i say is i have one

JR: no, it stipulates what's in it
... if you were only planning on extending to level a, why would you only need a language that has double or triple a

JS: best Benchmark document for the task
... can you test it?
... who evaluates success criteria

JR: anyone can make a claim for anyone

CS: vendor reads documents in planning for new dev cycle and decides to implement

JS: would tim pass that as testable?

JR: what breaks down for me, is when you say for the task

CS: many of them are going to be task specific

MS: why do we need a benchmark document and WCAG doesn't?

JR: they have techniques, for example a web page could make a conformance claim and they would support at the techniqeus they use

CS: no, techniques are non normative

JR: ok so how prove?

CS: i would talk about how it was built, how i tested
... techniques are non normative
... a conformance claim says I meet criteria X

MS: techniques may not be part of a claim
... why do we need this at all?

JR: otherwise for part B, it's totally ungrounded

B.1.3.1 as an example

MS: i am beginning to side with reed on overhead for tool vendors because of benchmark

CS: what i want is tools that help me meet with WCAG

JR: there is more to conforming to wcag than just meeting

CS: why duplicate in ATAG?

JR: if that's our requirment we have to pick this up let's say template, use of template meets wcag, that means there must be accessibility supported technologies
... how does dreamweaver know where it is going to be used?

CS: templates are designed based on where they are going in the end

JR: what about checkers?

AR: it seems more coherent to use wcag with clauses allowing other standards

MS: i still don't get this concept of benchmark documents
... i have this spec over and over and it just doesn't seem like uptake

JR: i know there is some verbiage in the BD (BD= benchmark document)
... for example, accessibility supported technologies are troublesome

CS: if i were building a tool for that market, what scenarios would my tool be in?
... and then you include not level a provisions for guiding users on what technology to use based on environment
... we would have incentive to claim ATAG compliance

JS: we should aim for that, uptake and getting people to use ATAG

JR: there are many scenarios in which it won't be WCAG at all...
... I am a critical person, I am not convinced you are actually checking for all you need to
... you aren't guiding for all I need

CS: you don't believe my checking tools do this? Here is my output, check this.

JR: my output might be strucutured like WCAG checklist or it might just be missing everything

JS: you can't force authors

JR: if somebody says in my experience it doesn't detect faulty headers
... doesn't put headers on my tables

CS: if you catch something i miss, they are going to report a bug, and they are going to fix it or not

JR: lay some of the cards on the table before, software isn't perfect

<jeanne> CS: The authoring tool may not have automated tools, but they can guide people to accessible choices.

<jeanne> JR: Do a straw poll to see if the group wants to give up the benchmark construct and have a more direct relationship wthh WCAG.

<MikeS> +1 for giving up benchmark construct and having a more direct relation with WCAG

<jeanne> JR: Do a straw poll to see if the group wants to give up the benchmark construct and have a more direct relationship wthh WCAG.

<jeanne> + 1 for giving up the benchmark

<Greg> Map to WCAG

+1 to WCAG

AR +1 to WCAG

Reed and AR with clauses for other standards

Resolution, give up benchmark construct and have more direct relation to WCAG

<jeanne> RESOLUTION: Give up the benchmark construct and have more mapped resolution to WCAG.

<jeanne> Map to WCAG with an allowance to other standards.

<jeanne> WCAG 2.0

<MikeS> scribe: MikeS

CS: does it make sense to look at part A?

JT: accessibility-related standards in ISO may become open and we may want to revisit linking to them as a client-side software guideline

JR: move through section A give guidance to those who are already following ISO or related standards

CS: we're assuming due dilligence with respect to other stanards has been done

JR: A.1.1

CS: web-based tools meet WCAG, non-web-based tools meet the standard appropriate for the platform

s/A1.1.1/A1.1/

<jeanne> editors note: to go back through the document and reword "desktop" where necessary.

A1.2

delete A1.3

A2.1

<jeanne> A.2.1.1 is saved

<jeanne> A.2.2.5 is saved

JR: remove A2.3.1
... remove 2.3.2

<jeanne> A.2.3.3 is saved

<jeanne> A.2.3.4 is saved

JR: remove A2.3.5
... remove A2.3.6
... save A2.3.7

RS: can 2.4.1 be roold into A2.4.4?

JR: remove A2.4.2-2.4.5
... remove A2.4.6-2.4.7
... remove A2.4.8
... A3.1.1 covered elsewhere
... same as A3.1.2

<jeanne> ISSUE: Should A.3.1.2 remain in Part A because it relates to the Editing view of the tool or deleted because it is covered elsewhere?

<trackbot> Created ISSUE-155 - Should A.3.1.2 remain in Part A because it relates to the Editing view of the tool or deleted because it is covered elsewhere? ; please complete additional details at http://www.w3.org/WAI/AU/tracker/issues/155/edit .

JR: save A3.1.3
... save A3.1.4
... remove A3.1.5
... A3.1.6 now Level A with modification
... remove A3.1.7
... remove A3.1.8-A3.1.9

A3.2

RS: not always what users want; consider moving to A3.2.2
... for A3.2.1
... basically, change from automatic save to option to save

JT: even acessibility considerations that are part of other guidelines may be emphasized (i.e. included) in the ocntext of an authoring tool

JR: remove A3.2.2-3.2.3

CS: 3.2.3 is actually not covered in WCAG so may want to save

RS: might as well keep it

JR: A3.2.4 removed

from WCAG 2.0:

general flash and red flash thresholds

a flash or rapidly changing image sequence is below the threshold (i.e. content passes) if any of the following are true:

there are no more than three General Flashes and / or no more than three Red Flashes within any one-second period; or

the combined area of flashes occurring concurrently occupies no more than a total of .006 steradians within any 10 degree visual field on the screen (25% of any 10 degree visual field on the screen) at typical viewing distance

where:

A General Flash is defined as a pair of opposing changes in relative luminance of 10% or more of the maximum relative luminance where the relative luminance of the darker image is below 0.80; and where "a pair of opposing changes" is an increase followed by a decrease, or a decrease followed by an increase, and

A Red Flash is defined as any pair of opposing transitions involving a saturated red.

Exception: Flashing that is a fine, balanced, pattern such as white noise or an alternating checkerboard pattern with "squares" smaller than 0.1 degree (of visual field at typical viewing distance) on a side does not violate the thresholds.

JR: keeping 3.3.1
... option to block

<jeanne> Issue: A.3.3.2 needs add an option to block rendering

<trackbot> Created ISSUE-156 - A.3.3.2 needs add an option to block rendering ; please complete additional details at http://www.w3.org/WAI/AU/tracker/issues/156/edit .

A3.4

JR: Keeping A3.4.1
... keeping A3.4.2
... keeping 3.4.3
... keeping A3.5

JS: 3.6.1-3.6.2 important and worth keeping
... A3.7.1 - meets kybd accessibility requirements
... A3.7.1-A3.7.2 meet A1

JR: remove all of A4.1
... remove all of A4.2
... keeping A4.3.1, 4.3.2
... deleting 4.3.3, 4.3.4
... keeping A4.3.5
... remove A4.3.6

<jeanne> Issue A.4.3.6 Error Suggestion: Go back and think about error suggestions that may be specific to the authoring environment.

JR: keeping A4.3.7
... keeping A4.4

<Jan> http://www.w3.org/WAI/AU/2008/WD-ATAG20-20080729/WD-ATAG20-20080729B.html

<jeanne> http://www.w3.org/WAI/AU/2008/WD-ATAG20-20080729/WD-ATAG20-20080729B.html

<Greg> Greg Now Scribing

<Greg> Jan read the introduction

<Greg> Editorial correction by MS

<jeanne> http://www.w3.org/WAI/AU/tracker/issues/96

<Greg> added text to address ATAG 2.0's ability to accommodate all disabilities.

<AnnM> can whoever is speaking speak a little louder please?

<jeanne> Cynthia: We would like to encourage the development of authoring tools that address needs of cognitive/learning disabilities.

<AndrewR> Issue:A.1.2.2: Should this remain in Part A as it's an exception to following the accessibility platform architectures which we are substituting in for much of Part A.

<trackbot> Sorry, bad ISSUE syntax

<Greg> Language supporting the need to encourage the development of authoring tools that meet the specialized need of the cognitive language and learning areas was added to the introduction

<AndrewR> Issue: A.1.2.2: Should this remain in Part A as it's an exception to following the accessibility platform architectures which we are substituting in for much of Part A.

<trackbot> Created ISSUE-157 - A.1.2.2: Should this remain in Part A as it's an exception to following the accessibility platform architectures which we are substituting in for much of Part A. ; please complete additional details at http://www.w3.org/WAI/AU/tracker/issues/157/edit .

<jeanne> Issue: A.1.2.2 - Should this remain in Part A as it's an exception to following the accessibility platform architectures which we are substituting in for much of Part A.

<AndrewR> Issue: A.1.2.3: Should this remain in Part A as it's an exception to following the accessibility platform architectures which we are substituting in for much of Part A.

<trackbot> Created ISSUE-158 - A.1.2.3: Should this remain in Part A as it's an exception to following the accessibility platform architectures which we are substituting in for much of Part A. ; please complete additional details at http://www.w3.org/WAI/AU/tracker/issues/158/edit .

<jeanne> scribe:Greg

<AndrewR> Issue: A.1.2.4: Should this remain in Part A as it's an exception to following the accessibility platform architectures which we are substituting in for much of Part A.

<trackbot> Created ISSUE-159 - A.1.2.4: Should this remain in Part A as it's an exception to following the accessibility platform architectures which we are substituting in for much of Part A. ; please complete additional details at http://www.w3.org/WAI/AU/tracker/issues/159/edit .

Remember to address the issue regarding the use of tools in combination to achieve accessible results in part B

<AndrewR> Issue: A.3.2.2: Where else will this be covered if we remove it from Part A? Won't WCAG only cover timing in the content produced by the tool and not the tool itself?

<trackbot> Created ISSUE-160 - A.3.2.2: Where else will this be covered if we remove it from Part A? Won't WCAG only cover timing in the content produced by the tool and not the tool itself? ; please complete additional details at http://www.w3.org/WAI/AU/tracker/issues/160/edit .

<AndrewR> Issue: A.3.2.4: Where else will this be covered if we remove it from Part A? Won't WCAG only cover timing in the content produced by the tool and not the tool itself?

<trackbot> Created ISSUE-161 - A.3.2.4: Where else will this be covered if we remove it from Part A? Won't WCAG only cover timing in the content produced by the tool and not the tool itself? ; please complete additional details at http://www.w3.org/WAI/AU/tracker/issues/161/edit .

Seeking clarification on the distinctions between level A, AA, and AAA

Conformance / Partial Conformance

<jeanne> CS: we don't want tools that meet Part A but don't produce accessible output.

<jeanne> JR: Allowing partial conformance in both directions puts the bottom step of the ladder closer to the ground.

issue should there be partial A conformance?

issue: Should there be separate conformance by parts?

<trackbot> Created ISSUE-162 - Should there be separate conformance by parts? ; please complete additional details at http://www.w3.org/WAI/AU/tracker/issues/162/edit .

Considering removing partial conformance criteria from the standard

removed the discussion of accessibility benchmark documents

Review Part A

Address AR's concerns

What happens if A.1.2.2 Accessible Alternative is removed? Is it covered elsewhere? Can it be safely removed?

Review Part A

preserve notion of functional equivalency

Under review A.1.2.2 Accessible Alternative, A.1.2.3 Deviation from Proper Use, and A.1.2.4 Additional Information

Final disposition is to continue with the removal of A.1.2.2, A.1.2.3, and A.1.2.4

Review A.3.2.2 Time Adjustable if remvoved does not appear to be addressed elsewhere according to AR

<jeanne> Issue-157: Close after discussion.

<trackbot> ISSUE-157 A.1.2.2: Should this remain in Part A as it's an exception to following the accessibility platform architectures which we are substituting in for much of Part A. notes added

Final disposition is to restore A.3.2.2

<jeanne> Issue-160: Closed. The text for A.3.2.2 was restored.

<trackbot> ISSUE-160 A.3.2.2: Where else will this be covered if we remove it from Part A? Won't WCAG only cover timing in the content produced by the tool and not the tool itself? notes added

<jeanne> Issue-158: Closed after discusion. AR is satisfied.

<trackbot> ISSUE-158 A.1.2.3: Should this remain in Part A as it's an exception to following the accessibility platform architectures which we are substituting in for much of Part A. notes added

<jeanne> Issue-159: Close after discussion. AR is satisfied.

<trackbot> ISSUE-159 A.1.2.4: Should this remain in Part A as it's an exception to following the accessibility platform architectures which we are substituting in for much of Part A. notes added

A.3.2.4 No Time Limits was revised and restored

<jeanne> Issue-161: Restored with rephrasing. AR is satisfied. CLOSE.

<trackbot> ISSUE-161 A.3.2.4: Where else will this be covered if we remove it from Part A? Won't WCAG only cover timing in the content produced by the tool and not the tool itself? notes added

<jeanne> PRINCIPLE 1. Follow applicable specifications and conventions

<jeanne> ...From UAAG

Principle A.1 changed from "Authoring tools must facilitate access by asssitive technologies" to "Authoring Tools Must Follow applicable specifications and conventions"

<jeanne> Cynthia: There are different ways that you can handle WYSIWYG in an authoring environment.

<jeanne> JR: A.2.2 can be removed because we covered it in the previous A.2.1

<jeanne> A.2.3.3 was editited to say "if it is misspelled is made available"

<jeanne> JR: How does A.2.3 compare with A.2.2. They are different.

<jeanne> A.2.4.1 can be moved up with other Presentation criteria. Move the rationale, too and then come back and edit them together.

This is scribe.perl Revision: 1.133  of Date: 2008/01/18 18:48:51  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

FAILED: s/A1.1.1/A1.1/
Found Scribe: reed
Inferring ScribeNick: Reed
Found Scribe: MikeS
Inferring ScribeNick: MikeS
Found Scribe: Greg
Inferring ScribeNick: Greg
Scribes: reed, MikeS, Greg
ScribeNicks: Reed, MikeS, Greg

WARNING: No "Present: ... " found!
Possibly Present: AR Andrew AndrewR Andrew_ AnnM CS Cynthia Cynthiha Exception Greg Issue Issue-157 Issue-158 Issue-159 Issue-160 Issue-161 JR JS JT Jan Jutta MS MikeS RS Reed jeanne trackbot treviranusjutta where
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy

Got date from IRC log name: 29 Jul 2008
Guessing minutes URL: http://www.w3.org/2008/07/29-au-minutes.html
People with action items: