wc: we may start scribe rotation
<wendy> http://www.w3.org/WAI/GL/WCAG20/tests/test195.html
mc:Chris say internationalization issues overcome by saying this is english version
ls: confused, is optional mean not relating best practice of check point or is it optional cause its unreliable
mc: means optional tests have no checklist
cr: can you explain?
ls: click here, issues or long alt tags sometimes ok so there is a problem with test
ag: propose tests go to general cause they are qualitative not really about html
wc: how bout a holding bin? on questionable stuff solve it later,, lets get through the tests - this stuff is f2f issues
mc: yep agree
ag: then we need usability best practice holding bin separate from guidelines difficult to keep up to date
cr: yeah its purgatory
mc: call it a holding bin
wc: all 3
all: agree
<wendy> ACTION: chris create list of all possible tests that are "in the bin" [recorded in http://www.w3.org/2005/02/23-wai-wcag-minutes#action01]
<wendy> ACTION: everyone discuss tests "in the bin" at the f2f and consider what to call them, where they go, what they look like. are they not dependable? optional? will we be able to keep them up-to-date if they are usability issues? [recorded in http://www.w3.org/2005/02/23-wai-wcag-minutes#action02]
ag: are there going to be tests for deprecated items
mc: probably not cause it says "here's how to do what you shouldn't do"
cr: except marquee and blink
ag: idea of mixing deprecated and non deprecated problem, let's pull them cleanly out
mc: that's off agenda , techniques structure, unless we can agree quick
cr: attribute called "deprecated" then fish them out in views.
mc: this is f2f stuff
wc: it would mean have discussion twice
ag: will decisions be circulated
JE: call in tomorrow? yes?
mc: we need back and forth with thursday all in
our group are invited to thurs
... talk about deprecated stuff next week
ag: we were writing logic into tests that could get difficult, but its ok to get test done, but there may be a logic problem
cr: let's just get through it and deal with
structure later, cause its hard for me to make all these small changes as we
go along, I've been making notes
... I'll get to bad errors but put off medium errors for later,
ag: chris, must be a lot a work, is there a way to share work?
mc: becky made suggestions on language,
cr: I can show the code to do the xml input put
if you are suggestion it would be easy
... are you offering to do work?
ag: just think it could be easier somehow sharing
mc: too many editors spoils the soup
... editors control a doc,
... we'll do more next week
cr: no, haven't used bugzilla, but I will
wc: it helps for scheduling and grouping issues etc...bugzy is good habit
jenae: I'll help
mc: test suite, structure , deliverables, ways
to get work done
... tues scheduling
... scary amount of work
... interoperable implementation of guidelines
jenae: browser matrix??
wc: brainstorm, in a perfect world what would
we do
... to get to candidate need two interoperable implementations, needed 2 of
everything two by two like the ark
... will decide in planing discussion
mc: we'll run out of time next week.
wc: dropping seeds to grow ideas for next week, for everyone to think about
jenae: suggest keep them all but there are 9 bugzy files regarding frames
mc: what is nature of open issues
jenae: 819
859, 870, 1068, 1069, 1107, 1125, 1144, 1198
<wendy> http://tinyurl.com/45hzn
wc: have totally different list
<wendy> http://tinyurl.com/4ms94
mc: these bugs seem a little unrelated to test
<wendy> http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-HTML-TECHS-20050211/#frames
<wendy> i don't see any issues linked from the html techniques section on frames re: issues
bg: test 33, has lots of examples, I think it might make people think they are the only ones
mc: representative but not exhaustive
mc: doesn't matter extension its the MIME
type,
... but email programs don't know that
... need to update this technique
cr: is the test that there needs to be accessible content
mc: that's my proposal
... but we are just saying anything in a frame needs to follow guidelines but
that's the same as every other container
cr: what if I say frame source must be accessible i.e. 2 examples linked to jpg or 2) link to html page that load with alt text
wc: ... discussed slide shows, is it
reasonable
... one frame of links
cr: text equivalent for image is in a whole different frame
wc: seemed it was accessible
mc: sometimes screen reader users like the
frames cause they can just jump out of a links frame on left margin
... title attribute of frame most important think
ag: idea was the frame element ever intended to link to image, was that speced in the html , must be relative to the spec, rather than how it is used, there are implications for interoperability
mc: html provides frame to link to any URI
ag: we need a harder line when it comes to deprecation, it seems a lot o our problems cause we allow more and more instead of saying hey don't use it"
ls: would it make sense use a meta data title
on .htm page, so if you have title on htm. page menu, title and description,
why insist re giving the title, when it is reasonable easy to get the title
from the source itself,
... other stands, html we have good mechanism of going to them and saying
"problem with your spec" like next week, do it through pf group, to review
other specs and say this is what we don't like.
wc: frames aren't in xhtml2 and they are not likely going to do many updated on HTML 4.01. they feel frames are fixed by using css. In XHTML 2.0 they seem to rely on div, section and css. we need to help people make leap, so problem is just dealing with authoring tools that still generate this stuff http://www.w3.org/TR/xhtml2/elements.html"
bc: look at test 35,36, suggest drop test requiring no frames. move to bin? UAAG issue?
mc: drop 35 cause in spec, drop 36 cause user agent issue??
bc: yup
mc: we should keep 33
ag: this browser matrix, is that what's in the there,
bc: it was just what browsers, supported what
ag: it would be great to have a list of browsers to see what supports what
mc: we should consider that
ag: we could strike through that
mc: its long process
wc: not our job, but UA group has one that is less than perfect...
<Michael> ACTION: Michael update HTML tech #frame_html to be generic to "accessible formats" [recorded in http://www.w3.org/2005/02/23-wai-wcag-minutes#action03]
mc: while questions about its validity there is enough support for 33 to go straw poll
cr: which sc - i did 3.1 but mike has 4.2,
wc: why not 2.4 navigation orientation
bc: 1.1
mc: agree. half techniques are 1.1
mc: ben suggested removing no frame requirement because part of spec, and if the title is there you can use the frame effectively
bc: even without title UA provides links to pages that are part of frameset,
mc: no frames important in old days, how old is too old
bc: that is really old
cr: so 35,36 rejected?
bc: can go into bin but not high priority
mc: should reject technique also
<Michael> ACTION: Michael deprecate HTML #noframes technique [recorded in http://www.w3.org/2005/02/23-wai-wcag-minutes#action04]
BC: or just deprecate them
mc: if we add attribute will be ok for deprecated but might make deprecated techniques section
cr: 34 technique deprecated, jenae asked do we need the test...
mc: new bin for deprecated techniques
cr: let's reject it
mc: yup
... longdesc for frames dumb --reviewing external file to get info about
another external file
cr: 32 ready for poll
mc: think so
... link to 2.4. cause orientation aid
cr: what about title for documents
wc: yup
mc: GL 2.4 l3, sc 4
<wendy> 3.1 level 3 #2 - Section headings and link text are understandable when read by themselves or as a group (for example, in a screen reader's list of links or a table of contents).
mc: I think it is 2.4 but no sc for it
... think it points to hole in guidelines
wc: perhaps part of the issue for frames, creates more work, can we build case against frames rather than hole in GL
ag: should the value of the title attribute be the same as the page that is loaded
Mc imo not important but see a case for it
wc: 2 questions, point about how to navigate through content related to issue with headings, so I agree there, at one point frames were extreme change in context
programmatically identified, explicit notice in extreme change in contents, not only ??? but the action of selecting link so 3.2 perhaps better fit
wc: frame is very html specific
<wendy> 3.2 seems to be a good fit for some of these issues, since frames have been considered "extreme change of context" - http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-20050211/#consistent-behavior
mc: don't know answers but identified number of issues
wc: enter question of frame title and page title to list
mc: fix mapping later
cr: I'll leave 3.1L3#2 as wendy suggested
... 101 iframes,
mc: yup
wc: need tim here so go to test file review from wendy
<wendy> ACTION: jenae write a test case for test 167 and 101 [recorded in http://www.w3.org/2005/02/23-wai-wcag-minutes#action05]
<wendy> http://lists.w3.org/Archives/Public/w3c-wai-gl/2005JanMar/0522.html
wc: would add <span> to list
<wendy> http://lists.w3.org/Archives/Public/w3c-wai-gl/2005JanMar/0523.html
wc: link to structures and relationships prog determine
43-4 misuse of headings, should accept them
43-47
associated with structure & relationship
1.3 L1
<wendy> http://lists.w3.org/Archives/Public/w3c-wai-gl/2005JanMar/0524.html
37-41 reject them because would not let you out of headings
cr: its been changed.
wc: better form H# should not follow hn+h2
H followed by the next header or anything less
cr: reject 41 &42 cause following h5 can be anything
or h6 can be followed by anything
cr: so really only 4 test
wc: recommend acceptance
bc: have a hard time requiring H levels
... author could want it
for sidebar
wc: maps to several issues, we need to tell them the order in the techniques
bc: not convinced its a big accessibility prob
mc: level 3 for me, I see benefits
cr: not big problem , but not huge burden either, not week enough to be binned
mc: authors would think it is a burden
bc: it the point o H is for NAV, then use in templating, comes into conflict with main content of the page,
it gets muddy mixing site nav and main content H
bg: sometimes css order gets changed order of visual order different ...
bc: order about eye following, but there are many issues when dealing with navigation
wc: need to note John slating's comments
<wendy> reads from john's email: http://lists.w3.org/Archives/Public/w3c-wai-ig/2005JanMar/0369.html
wc: reiterates JS issue
bc: issue in the spec...pf is working on labeling blocks, no good solution in html, too big for us future spec needs to deal with it, making this requirement it burden
wc: we don't have semantics. we should table it
bc: don't agree with test Header following in order rejected
bg: me too
mc: can't think strong accessibility but I like it
wc: would give AT better chance
<ben> related post on this subject: http://www.meyerweb.com/eric/thoughts/2004/07/21/pick-a-heading/
dm: I could help change the culture of no headings to provide structure
ag: people don't know how to use headers cause they don' know uses, in early days of html big honking documents, not so, need to tell how and where to use headers instead of making rules
mc: that would shift it to general tech
wc: interesting meyer article but he is using H
in orders
... html issue
... not same issue in other technologies
... open issue about reading order, but reject these tests
<wendy> wac: should reject the tests (meyer has a good argument), however have an open issue about how to address using headings and reading order.
face-to-face meetings 28 February and 1 March so not teleconference on 2 March.
We will meet 9 March.
CSUN begins on 16 March so we will not meet on that day.
We will meet 23 March even though we will be coming back from 20/21 March face-to-face meeting in l.a.