See also: IRC log
<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> 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?
<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> 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:
<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]
<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> 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
... 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
jw: issues with proposal, will
respond on list because of connection difficulties with phone
... would like proposals extracted from discussion
js: will do
asw: "Structural markup or coding
is used as required by technology spec" to resolve testability
... 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
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.
<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
... 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?
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
... 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
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
... 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.[End of scribe.perl diagnostic output]