<ben> Agenda:

Agenda review and Face to Face announcements (5 minutes)

<ben> js: 2.4 not on agenda today due to discussions/proposals in progress (not quite ready for group review)

<ben> js: logistics info for June F2F had been updated

<ben> http://www.w3.org/WAI/GL/2005/06/f2f-agenda.html

<ben> js: if you plan to attend, please register and make reservations as soon as possible

<ben> mc: discussed requirements, many action items pending

<ben> mc: in discussing this, there was an issue to address where requirements for the guide doc belongs

<ben> mc: change to structure of techniques was to remove short name and replace with what is currently task to reduce confusion

<ben> mc: still need to do some work on impact of baseline on techniques - for F2F agenda

<ben> mc: also talked about F2F agenda - lots to talk about (baseline, structure of techniques, test cases, techniques, etc..) we'll be asking people to do a lot of advance homework so we can be focused at F2F

<ben> mc: also reviewed techniques for 4.2, which is related to 4.2 guideline discussions

<ben> js: question about F2F - is it your expectation that techniques proposals will be discussed beforehand for presentation to full group or is the goal to write and revise proposals at the F2F

<ben> mc: hope is proposals will be made before the meeting, will likely result in propsoals to the larger group

<ben> js: other questions?

Techniques Task Force report (Michael: 5 minutes)

<ben> definition of baseline: http://lists.w3.org/Archives/Public/w3c-wai-gl/2005AprJun/0473.html

<ben> revised proposal: http://lists.w3.org/Archives/Public/w3c-wai-gl/2005AprJun/0364.html

<ben> js: consensus on definition of baseline first, will postpone discussion on conformance propsosal because that still needs work

<ben> loretta reads latest def of baseline (URI above)

<ben> js: motion is that we call for consensus on definition as read, accompanied by the notes

<ben> js: has been a lot of discussion on this on the list, hope we're ready for consensus - anyone want to speak against?

<ben> js: any objection to unanimous consent?

<ben> -- no objections --

<ben> resolved: accept definition of baseline as proposed (http://lists.w3.org/Archives/Public/w3c-wai-gl/2005AprJun/0473.html)

<ben> js: let's look at other pieces of 4.2 proposal, a number of reccs. to add existing SC under other guidelines that in effect would distribute the work of 4.2 throughout the guidelines

<ben> lgr: most of these are SC derived by our excercise of going through UAAG P1 items

<ben> lgr: there are 6 proposed SC, we'd like feedback about whether they make sense, are appropriate, etc.

<ben> lgr: one proposal about reading order to be discussed in 2.4 subgroup (proposal in development)

<ben> lgr: several proposals to add SC to 1.3 - one of them is about role state and value info be available - another is that the label of UI controls can be prog. determined and are explicitly associated with controls

<ben> lgr: both have to do with ensuring info about interactive content is exposed appropriately

<ben> lgr: sc for 2.1 (keyboard operation) that state and value that can be changed via UI can also be changed programmatically

<ben> lgr: final is a proposal for 2.4 about changes to content, value, ...., focus and relationships of content (idea is AT needs to know when changes have happened)

<ben> lgr: that's the quick overview of proposed SC that came out of the UAAG analysis

<ben> js: comments or questions?

<ben> bg: question on 2.1 - can you give an example? - am thinking about a handler to respond to an event - is that handler considered programmatic or do I now have to have a separate set of APIs that take particular information?

<ben> lgr: interesting question

<ben> bg: guess I don't understand exactly what that means

<ben> asw: my question is that if we require that everything be keyboard operable and you can in effect activate through keyboard input, then I'm not sure we need this SC

<ben> gv: one of my questions was that if everything can be done from the keyboard, then what was the goal with going beyond?

<ben> lgr: looking through notes to see why we added this - should I take this back to the list?

<Zakim> Michael_Cooper, you wanted to say like the proposals, question the home of the 2.4 one

<ben> ACTION: loretta to post answer to Becky's question to the list [recorded in http://www.w3.org/2005/05/12-wai-wcag-minutes.html#action01]

<ben> mc: I like them, the one proposed for 2.4 (changes to content, structure, selection...), feels very much like it doesn't belong in 2.4 based on our latest discussions, but think we should include it in WCAG somewhere, just not sure where

<ben> bg: I have similar questions about the one for guideline 1.3 (role state and value can be programmatically determined...) To me, that seems like a future type proposal. Right now, that's done for you by the user agent. Only way I could do it today is to use some of the work on DHTML roadmap. Means I can't try to create a component using JavaScript today.

<ben> lgr: question is whether that is a result we'd like

<ben> lgr: this req. would say that authors can't do this today, but when DHTML roadmap is done, then they will be able to do it

<ben> asw: what about a plugin or something written in another programming language?

<ben> bg: then they could do that today

<ben> asw: is this related to software req. in 508 about exposing information programmatically about objects

<ben> jc: can someone clarify at what level the SC is that everything must be keyboard operable

<ben> gv: level 1

<ben> jc: 2 issues with that - there are some things that can never be keyboard operable

<ben> jc: point 2, there is work being done for submission to w3c about drag and drop interactions

<ben> gv: is drag and drop support cut and paste?

<ben> jc: check Ian Hickson's log (I'll post a URI)

<joeclark> HTML 5 features for drag 'n' drop from Ian Hickson:

<joeclark> http://ln.hixie.ch/?start=1115899732&count=1

<ben> lgr: will always be the case that there is content that is valid, but not accessible - still need to look at what additional constraints might need to be established

<ben> js: we're about 25 minutes into this one, should wrap up soon. we have one action item so far

<ben> lgr: second item to look at proposal for 2.4 and see if there is a better home for it

<ben> ACTION: loretta consider alternative placement for proposed 2.4 criterion [recorded in http://www.w3.org/2005/05/12-wai-wcag-minutes.html#action02]

GL 4.2, continued (def. of baseline and revised proposal) (25 minutes)

<ben> john reviews proposals

<ben> proposed SC: http://lists.w3.org/Archives/Public/w3c-wai-gl/2005AprJun/0248.html#star

<ben> jc: I had a brainstorm - these days we're on this kick to avoid overlaps and redundancies in the guidelines - occured to me if we're recasting 1.3 as use web standards, obvious one is 4.1 (use spec). my big thing on that is we should require valid code at all times (presently a level 2)

<ben> jc: the other one is 2.4 (orientation) - seems that one is trickier, a lot of that has to do with structural markup, link elements, sections and subsections, etc.

<ben> jc: am wondering if 4.1, and possibly 2.4 should be moved under 1.3

<ben> js: point of info about joe's proposals - in keeping with that effort to avoid unnecessary overlap, group discussing 2.4 the other day (yvette, michael, myself so far) was to figure out how not to have them overlap.

<ben> js: lets see where that goes before we take up joe's suggestion to combine

<ben> gv: point of clarification - 1.3 was about separating struct. etc. you had said we're rewriting it into use web stds. - wasn't sure what you meant by that, use web stds. is more under 4.1 (use spec)

<ben> jc: for our own ease of abbr. reference, we can say that my proposal for 1.3 boils down to "use web standards"

<ben> lgr: joe, I think just boiling this down to "use web standards" is missing part of the goal here. (ex. PDF had to do some things to include structure in their specs - older PDF versions do not)

<ben> jc: just read something today (will post URI) that said you have to use latest versions of a W3C technolgy, which implies that you have to use XHTML 1.1 today. Loretta's example, there would be ways to encourage use of latest versions that do include the structure we need

<joeclark> Paper that mentions logical contradictions in WCAG 1.0: http://www.ukoln.ac.uk/web-focus/papers/w4a-2005/html/

<ben> gv: 2 items you mentioned (if you have structure, use it) PDF had structure, but AT couldn't access it ...

<joeclark> "Forcing Standardization or Accommodating Diversity? A Framework for Applying the WCAG in the Real World"

<ben> gv: can have structure in a standard, but no way for UA to access that structure

<ben> jc: but now you're dealing with user agents

<ben> gv: has come up a number of times, ex. for a while, apple had no screen reader, saying that if there was a screenreader, it could be made accessible... that's one of the issues we still have is how we create a fairly bright line about what passes and what doesn't

<ben> jc: sounds like you're restating the inaccuracy that PDF can't be read - better example than PDF (because that's contentious)

<ben> gv: one of the things we're looking at is when new techs come out, we want to be sure guidelines are written so that something that conforms is actually something that is accessible

<ben> jc: you mean like SVG?

<ben> gv: yes, that kind of a situation, need to look at why and how

<ben> lgr: I think the issue about whether something is theoretically or actually accessible is the baseline question that we've been talking around - think we'll be writing guidelines for which its possible to be theoretically accessible, but need to rely on whomever sets baseline to make sure they are reasonable and that techs in use contain sufficient support

<ben> lgr: I would claim that earlier PDF versions coulnd't be made accessible, wasn't until spec was updated that we could address some of these things

<scribe> scribe: Michael

<joeclark> http://lists.w3.org/Archives/Public/w3c-wai-gl/2005AprJun/0248.html

<joeclark> is my previous proposal.

jc: SC 2 we have decided this is implicit in using to spec
... trying to persuade authors to use structured formats when possible
... know that not always available

gv: this is not just part of "use according to spec"
... but might be correct within context of first SC - Structures within the document can be programmatically determined.
... don't know if that will be Level 1 because there are times you can't

jc: e.g., <embed>, but I no solution yet; nevertheless most Web content forever and ever will be in HTML so it's pretty relevant to majority of cases
... don't oppose keeping L1 SC 2, just think it could be moved

<joeclark> um, not "forever and ever"-- within the lifetime of WCAG 2.

lgr: introduces testability problems

jc: accept an imperfect world but don't want a site to fail because of edge cases

gv: remember anything that can't pass our requirements are barred from any site claiming WCAG conformance

jc: e.g., <b> and <i> vs <strong> and <em>
... Ruby in Japanese only in XHTML, so in HTML it's a fudge

<joeclark> ?

jw: issues with proposal, will respond on list because of connection difficulties with phone today
... would like proposals extracted from discussion

js: will do

asw: "Structural markup or coding is used as required by technology spec" to resolve testability issue
... not sure if this deals with Ruby example though

gv: works if you only use tech that allows you to encode structure
... issue if you use tech according to spec, and use a tech w/o structure, you pass without having to provide structure

asw: not clear why we need it, L1 SC1 covers what we need

<joeclark> http://lists.w3.org/Archives/Public/w3c-wai-gl/2005AprJun/0484.html

gv: collpase SC 2 into SC1?

jc: not opposed, some issues to work out

<joeclark> hold on.

<joeclark> Bare-bones language: http://lists.w3.org/Archives/Public/w3c-wai-gl/2005AprJun/0484.html

bc: advantage of SC2 gives us a better hook for techniques to say which parts of spec are more important than others - which types of structural markup sufficieint for a given baseline

gv: SC2 says _how_ to provide what SC1 requires

jc: which causes greater harm? a) keep both b) collapse 2 into 1
... probably b is greater harm because harder to explain; a is just a little redundant

gv: semantics = meaning for a lot of people, might read it as use structural markup to encode meaning of doc;
... need to explain narrower def of semantics

jc: this is understood among web standards people and least of our problems

js: let's move discussion to list

<joeclark> and the least of our problems with hard-to-understand terminology.

GL 1.3, continued (25 minutes)

GL 2.5 (25 minutes)

<joeclark> also, Success Criterion 2 is all about edge cases. and *I'm* all about edge cases. so we can be reasonably confident that we will take many examples into account by the time we're done.

asw: issues resolved by proposal
... 1343 user errors - might offend users - change to "input error"
... 1521 assist user to enter correct data e.g., input mask - propose new L3 SC (specific case so at L3)
... <reads proposal as edited by Ben>
... concern this is really usability, not accessibility, but at L3 don't care much
... that's my concern too, does it mean *must* provide input support all the time?
... more input mask stuff, when applicable
... look at Yvette's proposal

gv: accessibility extension of usability, could put all of usability here
... bright line is, would this stop people from being able to enter data correctly
... do sites actually have secret input requirements?

chorus: yes

gv: but is it a specific problem to PWD

bc: maybe this is a general technique

js: trip planner on Austin bus has specific requirements and doesn't tell you

My student loan site requires I enter payments a certain number of days in the future but doesn't tell me how many until I enter a date not far enough out

jc: <another example, scribe missed it>

asw: this is issue for everyone

mc: error recovery could be really painful for PWD, so better to have error prevention

al: error recover already covered

gv: this is one of many techniques under category of "do what you can to help users prevent errors"

js: so a technique, not SC

<joeclark> the example I gave was library (especially Library of Congress) subject headings, which are extremely hard to type exactly.

gv: seems more advisory than requirement

asw: let's not add the SC
... 1524 SC 3 not testable as worded, "significant" and "important"
... tried to quantify those terms

gv: usually worry about lists of conditions, but proposal is better than previous
... could miss an area but too bad, we can live with this since it's more objective, therefore support it

al: concept of financial transaction difficult to define since for me everything is it

asw: might make sense to move to L3 since it's so specific

gv: so easy to meet might be good to leave at L2

al: probably ok but impacts a lot of stuff
... feels like this SC is written specially for SAP and Oracle

asw: meant to be for online banking etc.

js: live with for now?

al: ok, but will examine later

gv: add "legal" to conditions

al: change "occur" to "conclude"

gv: they're synonymous in this situation

js: accept proposal w/ addition of legal?

jw: financial is a subset of legal

gv: having them as pair useful

js: unanimous consent

GL 3.1 (25 minutes)

oops, still on previous item

bc: propose we go ahead and reject the issues Andi proposed we reject

js: unanimous consent

<scribe> ACTION: Andi inform DRC of our suggestion [recorded in http://www.w3.org/2005/05/12-wai-wcag-minutes.html#action03]

<scribe> ACTION: Andi submit updated proposal to list [recorded in http://www.w3.org/2005/05/12-wai-wcag-minutes.html#action04]

now we're on this item

js: 63 open issues
... many focused on L3 SC re a statement that you've done your best is present
... some opposition to concept of a statement as a req, others concerned list of strategies weren't internationalizable, others concerned 3.1 too subjective and under heading of usability
... trying to find ways to write internationalized SC (thanks Makato and Takayuki), and to introduce testable stuff
... focused on education level and "readability forumulae"
... such formulae focus on word length, sentence length, syntactic complexity
... they assume shorter is better
... they're really about decoding, not understanding
... don't like readability indices but they are useful for certain reading disabilities where disability is around decoding, leaving less over for comprehension
... readability measurements usually expressed in terms of grade level aka education level
... could use that as a target around which to write techniques
... at level 1 introduced SC for description of educational level of intended audience
... can use international standard for education classification
... then at level 2 can ask content to meet upper secondary level or provide alternative version(s)
... since we assume average Web user has high school / upper secondary education
... also L2 SC re definitions of all words broken into two, one for definitions and one for pronunciation (move to L3)
... L2 SC re idioms, and L3 SC programmatic location of definitions of words used in a particular sense, combined into one L3 SC
... wrote guide doc for each of these SC to test the concept and explain further the proposals

gv: where is all this?

js: in attachment, .bak extension but is HTML

gv: L1 SC3 description of intended audience - generally we don't include SC that don't change accessibility, but this is just reporting; also some orgs can't report

js: guide describes benefits for content selection

gv: doesn't change accessibility, makes it easier to find accessible version

asw: education level is problematic, can have high education yet have LD clearly in scope here

js: describing education doesn't change access of doc, because people with LD at all education levels
... Dublin Core has an education level metatag

al: applicable to all languages?

js: yes, think so

This is scribe.perl Revision: 1.122  of Date: 2005/03/31 04:43:41  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/week/list/
Found Scribe: Michael
Inferring ScribeNick: Michael
Default Present: Michael_Cooper, Ben, Alex_Li, Christophe_Strobbe, Loretta_Guarino_Reid, JasonWhite, +1.202.558.aabb, John_Slatin, Becky_Gibson, Andi, Mike_Barta, Bengt_Farre, Makoto, Gregg, Joe_Clark
Present: Michael_Cooper Ben Alex_Li Christophe_Strobbe Loretta_Guarino_Reid JasonWhite +1.202.558.aabb John_Slatin Becky_Gibson Andi Mike_Barta Bengt_Farre
Agenda: http://lists.w3.org/Archives/Public/w3c-wai-gl/2005AprJun/0474.html
Got date from IRC log name: 12 May 2005
Guessing minutes URL: http://www.w3.org/2005/05/12-wai-wcag-minutes.html
People with action items: andi loretta proposal submit updated

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.