- From: Wendy Chisholm <wendy@w3.org>
- Date: Thu, 28 Apr 2005 21:28:59 -0400
- To: wai-gl <w3c-wai-gl@w3.org>
Minutes available at: <http://www.w3.org/2005/04/27-wai-wcag-minutes.html>
Action items:
[NEW] ACTION: Becky take 1.3
[NEW] ACTION: david send bg techs for 2.5
[NEW] ACTION: David take 4.2
[NEW] ACTION: dmd do either magnification tool have ability to zebra stripe
[NEW] ACTION: john research "inter-rater reliability" - is there a %
cutoff point?
[NEW] ACTION: michael add definitions for sufficient, optional to
section on definitions
[NEW] ACTION: michael delete clause about positive tests and conformance
[NEW] ACTION: Michael put information about relation of sufficient and
optional in baseline section
[NEW] ACTION: Michael take 2.4
[NEW] ACTION: wac ask tim about creating css test cases
[NEW] ACTION: wac new issue for 3.2 related to increasing font size
[NEW] ACTION: Wendy take 1.1
[1]W3C
[1] http://www.w3.org/
Techniques Task Force of the WCAG WG Telecon
27 Apr 2005
[2]Agenda
[2] http://lists.w3.org/Archives/Public/w3c-wai-gl/2005AprJun/0256.html
See also: [3]IRC log
[3] http://www.w3.org/2005/04/27-wai-wcag-irc
Attendees
Present
Becky_Gibson, Michael_Cooper, John_Slatin, Dave_MacDonald,
Wendy, Chris_Ridpath
Regrets
Tim, Ben, Christophe
Chair
Michael
Scribe
David, Becky_Gibson, wendy
Contents
* [4]Topics
1. [5]Plan for addressing techniques and test suites for 1.1,
1.3, 2.4, 4.2
2. [6]Requirements for Checklists and Techniques
3. [7]Mapping of script techniques to guidelines
* [8]Summary of Action Items
_________________________________________________________________
Plan for addressing techniques and test suites for 1.1, 1.3, 2.4, 4.2
mc: techniques for the guidelines above
wc: techniques taskforce michael john mike david becky wendy, chris on
call
... should take up test cases and techniques at same time to harmonize
... how to divy up the work???
... who's willing to do what, how much time do people have
... we have lots of people, if everyone took 10 techniques we could do
it
bg: seem to be loosing people from wed
wc: resourses is an issue
mc: that may be good because we can focus
w: if you are doing a lot of action items on this call don't do much
on Thurs
js: and vice versa
wc: next wed we need to talk about techniques....divy up work today.
by monday issue summaries, harvest more on Wed. then update propsoals
following week then following wed close
... i think some tech for 1.1 could be combined
... can't get into bugzilla
js: I got in the day before yesterday
wc: I'll ask gregg to restart that server
mc: I'll write up search tips
... take on tech for a guideline, in context of current, review each
tech related to a guideline keeping in mind the discussions in main
group thurs, discuss enndotes, bugzilla, then propose action, to
close,change, create new combine etc
setp2: go through mapping doc, think of techniques that appear to be
missing
css html and script
mc: test cases: go through the test cases for the techniques..
identify issues with existing test cases and propose additional test
casses
wc: I have ideas for test cases in CSS
... perhaps test cases with tim
<wendy> ACTION: wac ask tim about creating css test cases [recorded in
[9]http://www.w3.org/2005/04/27-wai-wcag-minutes.html#action01]
js: jim allen, james craig might help
bg: we have no JS scripts techniques now
mc: there open issues about how to write techniques in relation to
baseline
... havestin WAIG list ok to do also but not necessary
bg: but guidelines in flux
mc: make conditional techniques
js: we may close 1.1, 4.2, 2.4, 1.3 soon
wc: I'm tempted to take 1.1 cause I'm doing the guideline summary.
<Michael> ACTION: Wendy take 1.1 [recorded in
[10]http://www.w3.org/2005/04/27-wai-wcag-minutes.html#action02]
wc: labeling functional apps will work with Becky
bg: label is ot an alternative
wc: it is test that serves the same purpose
mc: label is label not an alternative
mc: will be alot of work - review list for info about GL plus techs
and tests
wc: so makes sense to work with person reviewing the GL
dm: have been working on 4.2
js: but there is a proposal on the list - can start with that
... hope is that WG comes to consensus on proposal - then techs group
can start work based on newly adopted proposal
<Michael> ACTION: David take 4.2 [recorded in
[11]http://www.w3.org/2005/04/27-wai-wcag-minutes.html#action03]
js: so hopefully don't have to sift through all the prior proposals
mc: so David is taking 4.2
<Michael> ACTION: Michael take 2.4 [recorded in
[12]http://www.w3.org/2005/04/27-wai-wcag-minutes.html#action04]
mc: MC will take 2.4
<Michael> ACTION: Becky take 1.3 [recorded in
[13]http://www.w3.org/2005/04/27-wai-wcag-minutes.html#action05]
bg: will take 1.3
<Michael> action 3 = David take 4.2, work with Loretta
<Michael> action 4 = Michael take 2.4, work with Yvette
bg to work with jc; dm to work with LGR
<Michael> action 5 = Becky take 1.3, work with Joe
mc to work with yh
wc: by Monday, may 2 we will all have sent an issue summary related to
the techs; proposals for changes would be great
... on May 9 will submit proposals for changes (based on dicsussion on
May 4)
... goal will be to discuss and close on May 11
... concerned that am travelling week of May 9
js: perhaps can coordinate with Ben?
wc: will be in Japan to will be ahead of all of you :-)
... will be at WWW conf and also speaking to JIS folks while in Japan
js: have sent draft of 3.1 proposal to JIS group since they are
concerned with English language centric issues
mc: work is assigned; will send a summary of what we are doing; May 2
is this Monday - so not lots of time, plan accordingly
dm: this includes bugzilla stuff - but we can't access bugzilla right
now
mc: will work on access
dm: only dealing with techs that are still related to gL
mc: sent emails with mapping of techs to guidelines - use those emails
as starting point
bg: all CSS techs showed as not being mapped
mc: then probably not mapped properly
... so consider techs that aren't currently assoc. and perhaps propose
associating them with a particula Gl
dm: have end to ends on my site that may help
mc: will try to include pointers to all sources in set of instructions
Requirements for Checklists and Techniques
<David_> [14]http://www.eramp.com/david/end_to_end/index.htm
[14] http://www.eramp.com/david/end_to_end/index.htm
<wendy>
[15]http://www.w3.org/WAI/GL/WCAG20/WD-wcag2-tech-req-20050426.html
[15] http://www.w3.org/WAI/GL/WCAG20/WD-wcag2-tech-req-20050426.html
mc: sent a change log to list
<wendy>
[16]http://lists.w3.org/Archives/Public/w3c-wai-gl/2005AprJun/0263.htm
l
[16] http://lists.w3.org/Archives/Public/w3c-wai-gl/2005AprJun/0263.html
<David_> end to end links above have associations that I eyeballed
from Guidelines to Techniues docs, (6 months ago)
mc: added info to intro about techs not being comprehensize - no
garuntee we cover every possible tech and technology
... following techs is not req. to conform to WCAG - is a set of well
thought out suggestions
... for most users is best way but not only way
... def. of reliably human testable - understood that want to remove
"80% of human testers would agree" so rewrote
... added def. of postitive and negative tests
... pos test demonstrates proper applicaton of tech; neg test
demonstrates improper application
... remove ref. to additional ideas
... added bullets about sufficeint and optional
... provided clarification of AND and OR
... removed req. for showing support by all AT (provide where approp)
... removed req. about untestable techniques
... added placeholder about baseline
... this is probably biggest thing I want to deal with
... removed appendix fields
... removed req. about general techs that are req. to conform
js: issues about req. for conformance
... positive test means test has been correctly implemented
mc: reads from doc about pos and neg tests
js: this should only be for techs that are sufficient
... may not need second clause, where tech is sufficient for
conformance a positive test would indicate conformance - something
like that
mc: wanted to say techs are a way to meet SC - a positive test is a
good thing for access.
js: but pos. test isn't always a garuntee of conformance
mc: action to delete clause about positive tests and conformance
js: sufficient and optional bullets added?
<wendy> ACTION: michael delete clause about positive tests and
conformance [recorded in
[17]http://www.w3.org/2005/04/27-wai-wcag-minutes.html#action06]
mc: reads info from doc
js: does that entail that we have to spell out benefit?
mc: why would we document an optional tech unless we thought it was
worth it?
js: so are we requiring ourselves to say what the identifiable benefit
is?
<Zakim> wendy, you wanted to ask in tech summaries, start to
categorize the techs as sufficient, future, etc?
wc: if we can describe them well - we can also use the categories for
a tech. summary categories
... if we want to categorize techs as optional, sufficient, future,
etc
mc: yes want to categorize; need that for when the tech spans
baselines
... at lowest baseline most techs are not optional but may become
optional in higher baselines
... or may be optional in one baseline and sufficient in another or
vice versa
wc: might be helpful if in the list of defs we list ooptional,
sufficient,
mc: so action to create definitions
wc: other categories?
<wendy> ACTION: michael add definitions for sufficient, optional to
section on definitions [recorded in
[18]http://www.w3.org/2005/04/27-wai-wcag-minutes.html#action07]
mc: analysis includes a not recommended category - where following
tech was destructive to access.
js: so there are places were we tell people what not to do
mc: no - it is a tech for one baseline that is not rec. for another
baseline
dm: do we want to say that a tech becomes optional in another
baseline?
mc: req. doc does say tech must specify the baseline; probably should
expand
dm: need to carefully define optional
mc: do we want to include the three baselines we have been discussing
so far?
bg: do need to define them
js: instinct is to not put in req. since they may be somewhat fluid
... techs need to def. baseline and which baseline a given techs works
in
<Michael> ACTION: Michael put information about relation of sufficient
and optional in baseline section [recorded in
[19]http://www.w3.org/2005/04/27-wai-wcag-minutes.html#action08]
js: but don't think req. doc should contain the definitions of
baseline
wc: req doc should be like a checklist to make sure we have done the
all necessary work
... saying what we are going to implement without saying how
js: say techs will ref. more than one baseline but not what they are
mc: so current wording about techs referencing the baseline it applies
to is ok
js: yes
mc: but still need to define baselines and where to include those defs
js: need to figure out grouping etc.
mc: so should add an agenda item for next wed. to discuss baseline
wc: there will probably be issues related to baseline in our techs
issues summary
... still see the 80% figure in the req. doc
mc: didn't remove it - wasn't sure if that was the action -
... at first deleted the sentence - then just updated the wording
dm: we are giving an exact % for an arbitrary number
js: actually 80% is a common target
dm: what is the exact term
js: inter-rater reliability
... one example is if hand 5 people the same set of content they will
agree on the rankings from best to worst but might give diff.
numerical scores
mc: we are tangenting a bit - do we want to zap the 80% testable by
humans sentence or not?
js: will take action item to see if there is agreement about % cut off
<wendy> ACTION: john research "inter-rater reliability" - is there a %
cutoff point? [recorded in
[20]http://www.w3.org/2005/04/27-wai-wcag-minutes.html#action09]
dm: can get a book about inter-rater reliability for $39.99 :-)
mc: is there more on req? do we need a break?
wc: suggest putting it on agenda again so people have more time to
review
mc: will update based on actions from today's call and repost req. doc
<David_> book called "handbook of inter-rater reliability"
<David_> [21]http://www.stataxis.com/interrater.htm
[21] http://www.stataxis.com/interrater.htm
Mapping of script techniques to guidelines
[22]http://lists.w3.org/Archives/Public/w3c-wai-gl/2005AprJun/0249.htm
l
[22] http://lists.w3.org/Archives/Public/w3c-wai-gl/2005AprJun/0249.html
bg: didn't map too many to 1.1. didn't go through existing script
techniques.
... went through a list apart, etc. tried to propose techs for 3
categories: 1. don't have scirpt, 2. can help w/accessibility 3.
scripts not helping accessibility, but common scripts and how to do
accessibly.
... only additional in noscripting e.g., about making accessible
pop-ups (using real links instead of javacript uris). mapped to 2.4
... felt a bit of a stretch, but using a tags appropriately.
... could probably go under 4.1 as well.
js: re: 2.4, is it supporting navigation?
... under 3.2 have extreme changes of context.
bg: tech is not to show how to mark extreme change of context.
js: if it's about using a tag might be about 1.3
wac: 3.2 level 1 #1 - "Any extreme change of context is implemented in
a manner that can be programmatically identified. " is using a in a
way that the ua knows what's going on. thus "programmatically
identified"
bg: the next group were to enhance accessibility
... focus to form element. 2.4, level 2, #4
... could also be #2 of that GL and level
... someone on the list said hadn't seen onload reliably.
mc: concept of setting focus is not under debate?
bg: no. someone else suggested "here's how i do it"
mc: like it, however, nothing before the focus is read.
bg: for filling out a form, is good.
js: google starting doing that/jaws supported, but field not labeled.
bg: leave it with one
mc: prefer to map to only one when possible. may have weak mappints to
others. technique should only map to one.
bg: next is how to catch onchange of input, validate, and set focus on
next element. sort of help ppl correct errors, but helps navigate
sequentially.
mc: also helps when do validation to do not mess it up.
js: what if script validates and input wrong?
bg: leaves you in the same field. however, this hard b/c depends on
the script.
... may not be able to come up with techs that are acceptable to the
group. need code and testing...
js: what is the main thrust of the technique? helping users avoid
errors and make ease to correct? or navigating sequentially?
... then 2.4 l2 sc 2
bg: navigating sequentially
... it assumes you are doing validation. vs the other technique that
says "move to the next field when there are 3 characters"
js: the 1st one goes under 2.5 (making easy to correct errors)
bg: say that it's about validation
input assist to change the background color or border of the element
with focus [GL 2.5 L2 SC1 (If a user error is detected, the error is
identified and provided to the user in text ) although color and
border isn't really text and this technique isn't specific to errors.]
bg: could be "help navigate" or "error handling"
mc: could also set text (not only color)
bg: adding text effects the layout.
input assist auto advance through fields. Fore example, a US phone
number input with 3 fields as you finish typing 3 numbers in the first
field the cursor moves to the next field and after three numbers there
jumps to the last field. This one is likely to be controversial as I'm
sure there are some people that dislike the auto advance behavior. [GL
2.4 L3 SC2 (When a page or other delivery unit is navigated
sequentially, elements receive focus in an order that follows
relationships and sequences in the content.)]
bg: some ppl like this one, others don't.
js: in an app, a user preference?
<scribe> ACTION: david send bg techs for 2.5 [recorded in
[23]http://www.w3.org/2005/04/27-wai-wcag-minutes.html#action10]
mapping makes sense
input assist to show a specific format in the field and user input
over types the format with the actual value. For example, a field for
a US social security number that shows "###-##-####" - as the user
types the # gets replaced by the actual input. [GL 2.5 L2 SC2 (If a
user error is detected and suggestions for correction are known and
can be provided without jeopardizing security or...
scribe: purpose, the error is identified and the suggestions are
provided. ) This technique is not specific to errors, though. ]
bg: instead of 3 fields, one field with format.
... put under 2.5, however the user hasn't created an error helps
prevent an error.
<jslatin> a mechanism is available to help users enter data correctly
looks like we need to propose a success criterion in guideline 2.5 at
level 2 or 3
mc: info needed to fill out the form is before the form
wac: google suggests - need info about how to fill in. not sure that
"###-##-####" will be intuitive to users.
question about creating a SC that might not be met by HTML. although,
seems that there are ways to do it in HTML.
wac: next steps?
figure out how to create an accessible pop-up (NOT a new window) that
can be made accessible. I'm not sure how to do this, yet, but it could
be used to provide more detailed information or help without leaving
the page. [GL 2.1 L1 SC1; (All of the functionality of the content,
where the functionality or its outcome can be described in a sentence,
is operable through a keyboard or keyboard...
scribe: interface. ) and GL 2.1 L3 SC 1; (All functionality of the
content is designed to be operated through a keyboard or keyboard
interface. ) ]
<David_> [24]http://www.eramp.com/david/general/
[24] http://www.eramp.com/david/general/
wac: extreme change of context?
<David_> above is general tech proposals for 2.5
discussion about how this could map to a variety of SC depending on
the example. could also map to 3.2 (if avoiding an extreme chnge of
context) or 2.5 (if helping user correct an error)
bg: pretty open ended. perhaps too early to map.
convert information provided via <link> elements into a select list on
the page. From alistapart.com entry: Dynamically Conjuring Drop-Down
Navigation [$1\47] [GL 2.4 L1 SC1 (Structures and relationships within
the content can be programmatically determined );GL 2.4 L2 SC 1 (
Documents that have five or more section headings and are presented as
a single delivery unit include a table of...
scribe: contents with links to important sections of the document. );
and GL 2.4 L2 SC2 (There is more than one way to locate the content of
each delivery unit, including but not limited to link groups, a site
map, site search or other navigation mechanism. )]
mc: tech to get around UA deficiency
bg: also navigation
js: level 2 under 2.4 (multiple nav mechanisms)
... l2 sc2 of 2.4
provide alternative text sizing on the page (in combination with CSS).
Here is an example for alistapart: Power To The People: Relative Font
Sizes [$1\47] Warning - it uses JavaScript uris :-) [This seems like a
helpful technology but I can't find a mapping???]
js: take it for granted that text is perceivable (by default). perhaps
a criterion that text is actually perceivable.
mc: related to tech on absolute size, have been unable to map them.
dmd: the only reason that we recommend rel is that there is a bug in
ie?
mc: css mapping to 1.3
need a criterion about font size and reflowing content when font size
increases.
js: fits under 3.2?
... b/c talk about consistency and design and effect on layout
... want to allow for changes in font size w/out blowing up layout
bg: it's hard to do.
js: specify a threshold, beyond which it is not the designers
responsibility
dmd: address what % users can increase font size?
wac: what's the general rule of thumb from moving from increasing font
size in browser to using magnification software?
<scribe> ACTION: wac new issue for 3.2 related to increasing font size
[recorded in
[25]http://www.w3.org/2005/04/27-wai-wcag-minutes.html#action11]
formatting table rows to distinguish one from another. This should
help the readability of all users but particularly screen magnifier
users if the table is wide. Another alistapart example: Zebra
Tables[$1\47] [GL 1.4 L1 SC1 (Any text that is presented over a
background image, color, or text can be programmatically determined. )
although that is a bit of a stretch since the technique itself...
scribe: is using color]
discussion of benefits - people who use magnifiers, people with
learning/reading disabilities
mc: may fit under understandable
js: perhaps an optional technique under 3.1 or 2.4 (re: making tables
more navigable)
... perhaps another mechanism for locating content
discussion about variety of places it could map to.
wac: depends on primary benefit - if learning disability, 3.1. if
magnificiation, orientation and 2.4
<scribe> ACTION: dmd do either magnification tool have ability to
zebra stripe [recorded in
[26]http://www.w3.org/2005/04/27-wai-wcag-minutes.html#action12]
dmd: i've been looking re: inter-rater reliability and 80% seems
reasonable number. 70% they say is low, 90% is high. sent john
articles have found.
next week: issue summaries for techniques/test cases, baseline,
requirements, script mapping
Summary of Action Items
[NEW] ACTION: Becky take 1.3 [recorded in
[27]http://www.w3.org/2005/04/27-wai-wcag-minutes.html#action05]
[NEW] ACTION: david send bg techs for 2.5 [recorded in
[28]http://www.w3.org/2005/04/27-wai-wcag-minutes.html#action10]
[NEW] ACTION: David take 4.2 [recorded in
[29]http://www.w3.org/2005/04/27-wai-wcag-minutes.html#action03]
[NEW] ACTION: dmd do either magnification tool have ability to zebra
stripe [recorded in
[30]http://www.w3.org/2005/04/27-wai-wcag-minutes.html#action12]
[NEW] ACTION: john research "inter-rater reliability" - is there a %
cutoff point? [recorded in
[31]http://www.w3.org/2005/04/27-wai-wcag-minutes.html#action09]
[NEW] ACTION: michael add definitions for sufficient, optional to
section on definitions [recorded in
[32]http://www.w3.org/2005/04/27-wai-wcag-minutes.html#action07]
[NEW] ACTION: michael delete clause about positive tests and
conformance [recorded in
[33]http://www.w3.org/2005/04/27-wai-wcag-minutes.html#action06]
[NEW] ACTION: Michael put information about relation of sufficient and
optional in baseline section [recorded in
[34]http://www.w3.org/2005/04/27-wai-wcag-minutes.html#action08]
[NEW] ACTION: Michael take 2.4 [recorded in
[35]http://www.w3.org/2005/04/27-wai-wcag-minutes.html#action04]
[NEW] ACTION: wac ask tim about creating css test cases [recorded in
[36]http://www.w3.org/2005/04/27-wai-wcag-minutes.html#action01]
[NEW] ACTION: wac new issue for 3.2 related to increasing font size
[recorded in
[37]http://www.w3.org/2005/04/27-wai-wcag-minutes.html#action11]
[NEW] ACTION: Wendy take 1.1 [recorded in
[38]http://www.w3.org/2005/04/27-wai-wcag-minutes.html#action02]
[End of minutes]
_________________________________________________________________
Minutes formatted by David Booth's [39]scribe.perl version 1.122
([40]CVS log)
$Date: 2005/04/27 16:07:51 $
[39] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[40] http://dev.w3.org/cvsweb/2002/scribe/
_________________________________________________________________
--
wendy a chisholm
world wide web consortium
web accessibility initiative
http://www.w3.org/WAI/
/--
Received on Friday, 29 April 2005 01:29:20 UTC