See also: IRC log
mc: will review the 2.4 issues post
mc: reviewed techs mapped to 2.4 and found
issues and reviewed test cases
... then reviewed SC and looked for other techs to map or propose new one
... site map is mapped to L2 SC1 - believe it should be L1 SC2
... group agrees
... test case refers to precense of site map but doesn't show what it looks
like - not sure if that is an issue
wc: curious - were you thinking about baseline as you reviewed?
mc: not as much as probably should have
... should add todo to clearup in next week
js: ? about how to identify sitemap in a test; site map is not one of the prefined rel values is it?
mc: no - not one of predefined values currently
js: is it for xhtml 2.0
yh: might be currently - will check
cr: can update the test cases with realistic
site map
... should I just put in a site map example?
js: is there an actual "site map" attribute - would make it easier to test for
mc: need to work out details later in interest of time
<wendy> rel linktypes: http://www.w3.org/TR/html4/types.html#type-links
ls: are we defining a good enough site map? -
many are too simple so need to define what it is and what we want from it
... am writing role for Xhtml 2 and it includes site map
<wendy> note to michael and chris (don't need to discuss on call): wording of test is concern (it says 'must provide site map' and needs to inherit mapping to SC)
<Tim> Do we have an unambiguous definition of "site map" ?
<leasa> and also what is good enough in a site map?
wc: applicable to several test cases - use of word "must" and correct mapping to SC to test and tech match
<leasa> what is too much info?
yh: site map is not one of the rel attributes in HTML currently
<wendy> ACTION: wendy send comments to chris about xml and updating mapping from test cases to SC [recorded in http://www.w3.org/2005/05/04-wai-wcag-minutes.html#action01]
mc: move on to collection info
... propose remap from reading order to L2 multiple meanings or L1
relationships
yh: think it applies to L2 multiple means
mc: some confusion on diff of 1.3 and 2.4 - there is a diff and need to widen the gap then can bemore clear abt where tech maps
yh: rationale of tech is to provide alternative nav. so multiple ways to find info is most applicable -L2 SC2
mc: is this only necessary when doc contains formal structure?
yh: esp. useful if doc does NOT contain formal
structure
... always useful to provide separate link elements even if not in the actual
content
mc: but more in optional category
yh: but is an alternative method
mc: tech probably gets marked as optional but itis useful
group: agrees
mc: suggest addn test files and tests should
use real links
... linear reading order of tables
... like but SC is currently under alot of disc. right now
yh: currently 3 options for SC - delete becuz
already covered; gets promoted to L1;
... so keep tech mapped to current SC and tech will move with it
mc: vote for SC kept at L1
... suggest remove comment about CSS tech
yh: are there css techs to address logical
reading order?
... since can use CSS to arrange things visually in different order than doc
order
mc: will mark as open issue
... there are evaluation suggests that should be moved out of tech itself
js: this info is distinct from testing?
mc: yes, refers to using eval. tools and points to ER group
js: does this go in resources section of tech or be removed?
mc: ok in resources
... intro on layout tables talks abt what they are and we don't like them
... but don't review that in this particular tech - could be lost if don't
have access to or read layout table intro
... should add to this tech
bc: add a link / reference to intro info rather than repeating in tech
al: agree
mc: will do that
... what about linearizaton of data tables?
... tech is not clear about that
js: in 2005 can assume that data tables are
handled properly by AT if marked up correctly
... need to make clear that we are making this assumption - but this might be
handled at baseline
mc: issue 248 - automated differentiation of
data tables
... don't support those because they are hacks and can't count on authors
using them
<leasa> I do not think the role is a hack
mc: but many people are behing this so need to address
yh: isn't this if it uses th it is data and if not is layout?
mc: but can't assume that - not a perfect
world
... issue (248) remains open
js: long discussion on IG list about this
mc: guess have to own proposing something
... another issue says need to make a stand on use of tables for layout
<jslatin> we could say *that* clearly: don't want to encourage, but can't say no
mc: other issue says we have to assume tables
for layout will be around for awhile so need to "allow" use
... agree with Jslatin comment above
... test cases should start with assumption that we are allowing layout
tables
... updated test cases to show table that linerizes and one that doesn't
rather than showing data table vs layout table
... link groups
<jslatin> dhtml roadmap is doing stuff with <link rel="navigatoin" href="#navbar" title="Global navigation"> (for example)
<jslatin> jon gunderson has an example working in HTML 401 with his Acccessibility Extension
ls: roles being created in xhtml 2 so we have
the ability now to add terms that we need into the role attribute
... so can say that role of this table is a layout
... this isn't only for layout tables - we should think about roles as we go
through the techs
... and consider if roles can help us
mc: good point to discuss on list
yh: seems like logical sets are rates as more imp than repeated material
<leasa> this is part of the road map..
yh: navigaton repeated on every page is repeated material but not a logical group
mc: so still further discussion needed
<jslatin> "repeated: becomes an issue *because* it's repeated
http://lists.w3.org/Archives/Public/w3c-wai-gl/2005AprJun/att-0345/00-part
address element: resolved - get rid of it.
Section headings
ls: working on metadata techniques related to this. would like feedback.
js: the techs that ls writing are not general
techniques, they are very specific to a particular to a specific type of
semantic markup. however, even if they were finished and get the review you
want, would not address the need identified in these ed notes. not a
critique, a distinction between rdf techniques and the way general techs
written so far seem to be working. they work together.
... perhaps some of the things in the guide will also address some of these
issues.
ls: have a set of techs to add, e.g. use link
element to add semantic info - not using rdf.
... happy to add to rdf techs if that doc will go somewhere.
js: we have a document called "general techs for wcag 2.0"
hello?
hmm. my connection just cut out for the end of that discussion.
<scribe> ACTION: john and lisa take discussion about guide/general techniques/metadata techs to the list [recorded in http://www.w3.org/2005/05/04-wai-wcag-minutes.html#action02]
bg: 2 issues 925 (only 1 h1/page and 1st
element) - seems that most ppl disagree with that. propose we close 925,
don't require only one, write up the info from that discussion into tech.
good practice to use 1 and to start with but not required.
... 1070 is about ordering (h2 follows h1) - we discussed that. think we
addressed that when we updated the test. think we can close.
... no consensus on the list, but all the msgs read seemed to agree.
mc: ok to close and not require.
... if we're not restricting under 925 do we even care about ordering?
bg: html spec suggests they should be
js: the order can matter. a SR that announces header level...can be startling to get h4 then h2. not that should be disallowed.
ls: reasons for why it does matter.
... h1 doesn't have to be the first, but has to be in the right order.
mc: doesn't have to be first, but ordering is an issue.
<jslatin> i think there's a <sectin> element in xhtml2
bg: attempt to address issue w/proposal otherwise open new issue
Emphasis
js: my proposal for 3.1, there is a tech re:
emphasis
... it could map there iinstead of 1.3
bg: do we want to include subtleties in
technique or in test case?
... or just assume that strong/em are best and ppl using b/i are doing so
knowledgeably.
mc: don't think ppl are considering
semantics.
... like idea of being semantics, not sure much diff in UA support or
author's intent.
js: wrt 3.1, thought about SC to identify main
ideas in a paragraph. that seems that emph would have semantic function.
... work in AAC community might find that a helpful way to ...
from matt's blog: http://www.bestkungfu.com/archive/date/2004/05/understanding-semantics/
and http://www.bestkungfu.com/archive/date/2004/05/strongly-emphasizing-semantics/
requirement: future techs don't need test files (??)
(related to Short Quotations (future))
In-line structural elements to identify citations, code fragments, deleted text, etc.
bg: several ednotes. propose that we remove it. should be covered by guide or rework tech and create test files.
wac: covered by previous blog entries. think covered by emphasis rewrite.
bc: muddies the waters around strong/em
wac: could keep separate or could create a tech for semantic markup.
bg: rewrite this tech and provide more about how to use them and why
Ordered lists
tb: proposed content for tests 149 and 150 but not to lists
mc: don't think we need this tech anymore.
bc: it belongs in css techs, think it is
problematic use of css. css is introducing content.
... think it is an example of what not to do instead of what to do.
... UA testing, Jaws and window eyes do a good job identifying nesting. hpr
doesn't summarize how many nested lists.
... say we remove it, it's UA responsibility
resolve: remove technique 6.1
bg: take these proposals and take to list?
mc: yes, the plan is today is issue raising next week is proposal. ideally we should have gotten through all of summary. next week proposals.
got through 6/19 of techniques
mc: since david not here, table 4.2 issues.
... need to discuss baseline.
<Tim> Do we have a definition of what we mean by "baseline"?
<jslatin> tim, definition of baseline is up for discussion on the WG call, last week and again today
mc: in reqs, say that each tech should identify baseline.
http://lists.w3.org/Archives/Public/w3c-wai-gl/2005AprJun/0095.html
mc: put defns in reqs for sufficient, optional,
required
... propose that we continue that exercise and mark each tech w/above.
... wcag wg should recommend which baseline.
... tentative recommendation that we use base baseline
http://lists.w3.org/Archives/Public/w3c-wai-gl/2005AprJun/0364.html
[1] Proposed Definition of baseline: The minimum set of technologies that can be assumed to be supported by user agents in order to access all information and functionality of the Web content.
[2] Proposed Definition of technology: "Technology" means a data format, programming or markup language, protocol or API.
wac: need to be careful about redefining technology since ATAG just decided to use our defn of technology.
mc: defn not descriptive enough.
... feel that is a proper defn, but only we will understand what it means.
js: needs plain language or example?
mc: needs expansion.
wac: perhaps that info is in "conformance requirements modifications?"
mc: do we know enough about baseline to continue discussion?
no disagreement
mc: propose minimal tech (html, not much else),
modern day graphical + AT (html, css, script. perhaps also java, flash, and
pdf accessibility), future (all features of all techs are supported according
to specs in UAs)
... future - to set a goal
... want some direction to the UA promised land
... put most of energy into the 1st 2
tb: diff techs for diff baselines? subsets?
mc: insight for us was that higher baselines allow you to follow fewer techniques
js: are there specific techs that jumped out in that analysis?
mc: main thing was when we marked techniques as
"not recommended" ex. format ordered lists (which we just discussed) was one
that was not recommended in future baseline)
... had questions about table structure techniques, another one was tabindex
and accesskey, alternatives for <object> etc. being problematic
js: interesting that you put it that way, I wouldn't have seen those as problems for the structure you're thinking about
wc: part of what I did was to try to apply these techniques to see if I agreed mappings for each technique - had a variety of questions
ex. meta refresh is a way people create webcams, but not mapped to 1.1
wasn't sure how that relates - I think there are changes that we can make that will work, but how does that relate?
another question was link element, a lot of this fits in future
third question is how specific are we about which DTD or Schema are we talking about (validating to DTD that allows <embed>?)
js: if we think in terms of how the proposed def. of baseline talks about technologies vs. user agents, then some of this becomes even more important
then we can be looking at collecting techniques for XHTML 2.0 as it moves toward finalization
wc: I agree that it's a useful excercise to consider baseline as we review these
mc: are people more or less behind those 3 baselines?
js: I like it
tb: do those baselines represent a sufficient capturing of current and future best practices? I'm concerned about baseline implications regarding conformance.
<wendy> latest 4.2 proposal: http://lists.w3.org/Archives/Public/w3c-wai-gl/2005AprJun/0364.html
js: there are implications, good summaries on list from Loretta recently
mc: wonder if we should categorize each technique (sufficient, optional, not recommended) based on each baseline
wc: base/graphical/future vs. sufficient/optional/not recommended (diff?)
<wendy> each baseline has sufficient, optional, and not recommended techniques (9 combos)
wc: interesting in looking at results that there were some contradictions
mc: we did discuss somewhat, but didn't
update
... action could be to put info from mapping excercise in techniques and then
discuss/resolve contradictions?
<wendy> http://lists.w3.org/Archives/Public/w3c-wai-gl/2005AprJun/0010.html
wc: if we can all be voting (ex. test case
polls using WBS), that can help us collect data so that we only talk about
disagreements on calls
... still some issues with WBS form that we're trying to resolve
... could be anything (ex. proposed action items, etc.)
mc: process is somewhat overwhelming (though a lot of fun), but important to provide concrete proposals
js: knowing in advance that it takes a long time, one thing we should ask people to do is assume that they will spread it out over a few days
bg: not that it can't be done, but tough to turn around in 2-3 days
js: trying to map out assignments so people will have more time to work on things
wc: I had 1.1, interesting to do both guideline and techniques summaries, person doing techniques summaries should be coordinating with guideline summary people as we go. recc. extreme programming model where you have two brains working on something
js: proposal there that we shoudl talk about - try to do for techniques summaries and proposals what we've done for guidelines summaries and assign them out for the next couple months so people know what their assignments are in advance
mc: agree we should do that, but we should also send weekly reminders to make sure people are working on them
js: we're experimenting with new system for
planning and milestone/assignement tracking
... maybe what we can do in interim is if you have favorite issues, you can
put in a bid for that so you don't get assigned random stuff
mc: action to incorporate baseline info into techniques, set up a voting system and to get assignments made on summaries
<Michael> ACTION: mc to incorporate baseline info into techniques, set up a voting system and to get assignments made on summaries [recorded in http://www.w3.org/2005/05/04-wai-wcag-minutes.html#action03]
wc: think it might be too soon to put in baseline info now, but include in summaries and incorporate once we have agreement
mc: agenda #4 was to assign issue summaries
<scribe> ACTION: john - issue summaries for 3.1 techs [recorded in http://www.w3.org/2005/05/04-wai-wcag-minutes.html#action04]
ah, I must be muted
bc: 2.3 - not much can be done at this point because tool needs development and intl. standards are not yet avail. - could have "don'
t use" techs, but beyond that measure is needed
js: 1.4 - gv is working with Aries Arditti on this
<scribe> ACTION: bc techs issue summary on 1.4 [recorded in http://www.w3.org/2005/05/04-wai-wcag-minutes.html#action05]
<scribe> ACTION: bg techs issue summary on 2.1 [recorded in http://www.w3.org/2005/05/04-wai-wcag-minutes.html#action06]
<scribe> ACTION: nobody techs issues on 2.2 (time limits) [recorded in http://www.w3.org/2005/05/04-wai-wcag-minutes.html#action07]
<scribe> ACTION: wc to talk to andi about techs issues on 2.5 [recorded in http://www.w3.org/2005/05/04-wai-wcag-minutes.html#action08]
<jslatin> morning, joe
wc: 3.2 guidelines summary is unassigned
... need to make decisions about what to do at F2F
mc: let's put that on the agenda for next week
3.2 techs summary unassigned
<scribe> ACTION: bc techs summary on 4.1 [recorded in http://www.w3.org/2005/05/04-wai-wcag-minutes.html#action09]
mc: script techs and requirements for next
week
... are we asking anyone to have done issues for next week or are we
continuing on the ones we've got
wc: I'm bumping 1.1 to week of 16 May
... we should talk about proposals for 1.3 and 2.4 and issues review for
4.2