Summary of 17-20 October 2005 WCAG WG face-to-face meetings
Present: Matt May, Michael Cooper, David MacDonald, Tim Boland, Sofia
Celic, Gian Sampson-Wild, Becky Gibson, Andi Snow-Weaver, Wendy Chisholm,
Gregg Vanderheiden, Ben Caldwell, Alex Li, Loretta Guarino Reid, Makoto Ueki,
Gez Lemon, Don Evans, Sandy Bartell, John Slatin
Summary by Guideline
General/overall
- Issue with use of the word "label" in several places. Editors will
address as needed, but intend to "identify" instead of "label."
- ACTION: lorretta and Gian will look at new SC or
checkpoint to deal with the inclusion of 10.2 (fro wcag1.0) in the new
2.0 (came up in discussion of Guideline 4.2 L1 SC4 [WCAG 1.0 - 10.2 Until
user agents support explicit associations between labels and form
controls, for all form controls with implicitly associated labels, ensure
that the label is properly positioned. (priority 2 in WCAG 1.0)]
- ACTION: sandy and wendy look at which guides we could
clarify that the functionality could be satisfied by the user agent.
Conformance
- someplace we need to discuss the fact that we have the sufficient
section in the guide documents - propose that we do this in conformance
section. be clear that what is in the sufficient sections is not the only
thing that can be done.
- ACTION: someone write guide for
baseline/conformance
Guideline 1.1
- resolution: Definition of non-text content,
"Content that is not represented by a Unicode character or sequence of
Unicode characters when rendered in a user agent according to the formal
specification of the content type. This includes ASCII Art, which is a
pattern of characters." [added to wiki]
- resolution: keep using functionality instead
of function (as suggested). determined that "function" is too limiting.
- Adopt all of the guides as is with the following editorial changes to
be addressed by the editors:
- guideline 1.1 L1 SC2: refer the following comments from the survey
to editors: LGR, Sofia Celic, christophe's comment re:
view/perceive
- guideline 1.1 L1 SC2: address the rest of andi's comments from the
survey (i.e., all of hers except the 1st one about the note). e,g, 2
and 4-9
- L1 SC2 - remove the note
- guideline 1.1 L1 SC3: address several people's comments about
label/identify, loretta's comments about common failures (use similar
wording as previously used) and benefits and examples, yvette's
comments about embed (use similar approach as 1.1 L1 SC1).
- guideline 1.1 L1 SC4: address Sofia's comment, "2. Intent section
specifically refers to "users listening". this needs to be
generalised. How about "users accessing the text alternatives"?" and
gian's comment, "What about images that are intended to excite or
manipulate the user? For example, on the site
www.liveinvictoria.vic.gov.au (which is aimed at encouraging skilled
migrants to migrate to Victoria) there are a lot of images which are
intended to make the user feel like Victoria is a great place -
exciting, vibrant etc." perhaps "sensory or emotional?"
- guideline 1.1 L1 SC5:
- add to examples clarification about difference between recorded
multimedia and live audio-only and live video-only.
- related to "label" issue above, this is another place where
label is used (in general technique)
- try to build this as an exception on l1 sc1 or figure out a
better construction - if you fail level 1 #1 the also fail this.
perhaps "except multimedia which requires, 1.2, etc. except live
audio-only and live video-only for which l1 sc5 applies"
- refer to andi's comments on examples
Guideline 1.2
Guideline 1.3
- resolution: adopt proposed definition of
"programmatically determined": can be recognized by user agents,
including assistive technologies, that support the technologies in the
chosen baseline. note: other SC use this phrase so we have
resolved to adopt this defn as our "working defn" and see if it works in
other instances as well.
- L1 SC1 - unclear if there is agreement about what structure to provide
at level 1. current sufficient techniques only include tables and labels
for form controls. does not include headings, lists, paragraphs. an example of a
"list" in the nav bar that's done with layout tables debate about
whether these are requried at level 1.
- L1SC2 needs more work. gv will take comments received on survey and
rework for next week.
- L2 SC1 - gv will also try to rework this one.
- and l2sc2?
- l3 sc1 - loretta will try to rework before next week
- l3sc2 - proposal from last week's discussion http://www.w3.org/2005/10/13-wai-wcag-minutes.html#item07
resolved to add (at last week's mtg) guide proposal at: http://trace.wisc.edu/wcag_wiki/index.php?title=Guide_to_1.3_L3_SC_2.
therefore - nothing to discuss and no action items with L3 SC2?
Guideline 1.4
Guideline 2.1
- L1SC1
- discussion about wording of SC that avoids or clarifies "described
in a sentence" (in All of the functionality of the content, where the
functionality or its outcome can be described in a sentence, is
operable through a keyboard interface. returned to proposed
wording from june f2f which said, "Not resolved L1 SC 1: All
functionality of the content can be operated through a keyboard
interface except whenA. input is analogue in nature, or B. the input
proces inherently depends on visual feedback [group liked the
construction with a list of exceptions but did not agree on a list of
exceptions. Sent back to group]" other comments: L1 SC1: current
proposal removes "described in a sentence" - do we want to limit SC1
to only refer to simple funtionality (will need to describe) or is is
req. for all content? Has to do with time based movement that adds
functionality ( isn't that gestures?) Can we look at Wendy's 1.1 idea
of number of actions or type of functionality?Is this related to 4.2
proposal?
discussion if we should include "non-time dependent"
- time dependency covered by 2.2, but concern that ppl won't make the
connection between this and that one. therefore, discussing a note or
other clarification.
- ACTION: gregg clean up intent and write more
examples for guideline 2.1 l1 sc1
- L3SC1 - resolved to continue using "functionality" instead of suggested
"function" because "function" is too limiting.
- Editors:
- L1 SC1 loretta's last comment (benefits and examples)
Guideline 2.2
- L1SC1
- resolution: accept the proposed shorter SC (At least
one of the following is true for each time-out that is a function of
the content:....) since the first part of the SC is coverec by a
Level 3 SC. discuss designing without timeouts as a situation in the
guide doc, clarify that the second point is about key presses and
that the time is only 2 seconds so it wouldn't make sense to warn the
user. will add as a 3rd situation in the guide.
- resolution: Accept Gregg's proposed definition of
"activity where timing is essential" as "activity where timing is
part of the design of the activity and removal of the time element
would change the functionality of the content "
- Resolution: Make situation D the first one in the
list
resolution: situation at level 1 only
in cases where the author controls the server. Add note - if author
does not control the server, there is no requirement.
some people interpreted the success criteria as
applying to server timeouts even though it says "for timeouts that
are a function of the content." proposal for a note - "this SC does
not currently cover server timeouts" which some members of the
working group think is a problem.
- ACTION: Michael, Andi, Don, (and maybe Alex) to
discuss concerns about inclusion or exclusion of server-time outs
with this SC. Develop proposal for SC that addresses concerns raised
during the discussion.
- ACTION: David - develop a definition of timeout
that includes the scenario of holding down a key and notes that there
are timeouts that occur in the content and those that occur in the
server
- ACTION: Loretta and Gian to discuss at a break and
make a proposal regarding how to handle example of auction
- editors:
- L2 SC1 - looks ready to go. several editorial issues. examples and
benefits needed.
- L2SC2
- example - for L2sc2 - an animation where it is essential to
expressing the idea but pausing it does not invalidate the activity.
e.g., how stuff works animation of car engine
- example 2 - stock ticker. if it doesn't move can't see all the
stocks, but stopping it does not invalidate reading it.
- example 3 - 2 people in "dog fight" in competitive game one person
can pause and that would invalidate the activity
- exmple 4 - an auction - can not pause the timing of an auction
because of the nature of the activity.
- clarification that difference is that with stock ticker can't pause
indefinitely...and it's not slowing...if you can't freeze it w/out
invalidating then timing is essential.
- resolved: content can be paused by the user unless the timing or
movement is part of an activity where timing or movement is
essential. rationale: the rewording of the SC (proposed
in the guide) had several "ands" and "ors" that made it difficult to
parse.
- difference bewteen pause and freeze. pause means that when you
"release" it continues" but when you release a "freeze" it doesn't
(necessarily) .e.g., you could pause a stream and when you start
again it starts where you stopped it. freeze is when you pause a
stream and when you start again it starts where it is now at in real
time. removing "freeze" entirely in favor of "jump to current..."
- L3 SC1
- L3 SC2
- "the availibility of" deleted from the SC since caused more
confusion than clarity.
- stock ticker would not be covered because pausing it could result
in loss of property (thus could be an emergency situation). however,
ads, spam pop-ups, etc would have to be paused according to this
criterion.
- The user can postpone or suppress all interruptions, except those
involving emergencies. rationale: gets us out of using
"non-emergency" in SC so we can define "emergency" instead
- diff b/t this sc and previous is that in previous one user
interrupts content, in this one content interrupts user
- L3 SC3
- resolution: postpone the question of moving L3 SC3 to
level 2 and possibly to level 1 until the next meeting when we have
more information.(becky's action items)
- ACTION: becky ask security expert about techniques
for guideline 2.2 l3 sc3 (provide information for discussion about
moving this to level 2)
- ACTION: becky and david ask for clarification on
roberto's comment, " I think this should be impossible for some
server-side web application and for some technologies (eg. Session
for IIS). Shall we suggest to not use session and IIS web
application?"
Guideline 2.3
Guideline 2.4
- resolution: change L1SC1 to use "programmaticallly
determined" instead of "programmatically identified": Navigational
features of the content can be programmatically determined.
rationale - just adopted a new definition of "programatically determined"
and this is what we mean
- issues with L1SC1
- concern about definition of "programmatically determined" and that
WCAG 1.0 checkpoints were mapped to various crierion, but definition
of "programmatically determined" has changed (have to revisit mapping
when we're done anyway, this is another issue to keep in mind as we
revisit)
- do "navigational features" include headings? or are they just links
and buttons?
- What about groups of links - is the group a navigational feature or
is it structural?
- from the 13 June 2005 F2F discussion: "Rationale: Level 1 SC 1 used
to be the same as 1.3: "Structures and relationships within the
content can be programmatically determined.". We found that for 2.4,
we should only focus on the functional requirements necessary to
facilitate finding, orienting in and navigating through content.
That's why we changed the wording into: "Navigational features can be
programatically determined"."
- how does this relate to guideline 1.3? is it that:
- action: Andi, Wendy, Loretta, David to work on GL 1.3 and 2.4
together to make sure all situations are covered
- L2SC1
- issues: why is this important? to support different learning
styles.
- how does this apply to web applications? or simple sites where more
than one way is not needed?
- Proposals to consider:
- More than one way is available to locate content within a set
of delivery units except for where the content is the result or
step of a process or task.
- When the purpose of a set of delivery units is to provide
information, more than one way is available to locate content
within the set of delivery units.
- ACTION: wendy, becky, alex work on proposal for
guide for guideline 2.4 l2 sc1
- Later discussion (why did we return to? are these about l2sc1 or
was that mismarked?)
- discussion about using asterisk to mark required field. is a
"standard" because so widely used so we should address it or is
it a hack that we should not encourage?
resolution: update first bullet
in input error definition to say: information that is required by
the delivery unit but omitted by the user.
resolution: move If an input
error is detected, the error is identified and provided to the
user in text. to Level 1
- ACTION: ben to research why this was moved
down to Level 2 (it was at L1 in April 2003 draft)
resolution: add highlighting or
visually marking as an additional technique
editors: things listed under HTML techs are
general and should be moved to general techniques (or at least
not listed as HTML techs)
- L2SC2
- discussion about technique of ordering page so content is first
- discussion about whether skip links have to be visible
- no resolutions
Guideline 2.5
- L2 SC2
- resolution: cut "the error is identififed and" from
the last part of the SC" (it now reads, "If an input error is
detected and suggestions for correction are known and can be provided
without jeopardizing the security or purpose of the content, the
suggestions are provided to the user."). rationale - this is already
mentioned in previous SC and would allow us to avoid repeating many
of the same techniques.
- resolution: keep content in WCAG glossary but don't link to it from
every use (too many)
- editors: need to fix the example so that the link is real and
within W3C space
- action: david propose a success criterion about helping users avoid
mistakes.
- editors: will rework the intent section based on the change to
remove the identification of the errors from this SC
- ACTION: Loretta to review and revise GL 2.5 L2
SC2
Guideline 3.1
- L1 SC1
- resolution: move the html text direction on block elements
technique to L2 SC2
- resolution: modify situation B to replace the word "AND" with
"identify" and update intent section to include info about text
direction
- add note that we need to include information about multimedia
- L2 SC1
- ACTION: wendy to pull examples from existing info into Guide for
3.1 L2 SC1
- capture RC comment into the intent section of this Guide
- resolution: add option technique "also mark individual words,
especially when they are links to versions in other languages
(Deutsch, français, Nederlands, castellano,...).
- not defining "that have become part of the primary language of the
content" b/c too difficult to do. some languages are changing quickly
others do not have dictionaries. however, there is a concern that
this is not defined. also concern about "primary." but everyone seems
able to live with as is.
- accept BC proposal for edit to intent section
- L3 SC1
- L3 SC2
- ACTION:john and gregg to work on the definitions
of jargon, idiom, and words in an unusual or restrcited way -
consider loretta's proposal to investigate if can tie to reading
level (model after l3 sc5)
- resolution: guide doc is ready to go *except* for technique on dfn
(discussion of editorial note) and definitions (gregg and john's
action item)
- however then there was proposal to move to level 2...therefore the
guide doc is ready, but need to discuss level of the SC (right??)
- editors:
- resolution: <dfn> element in advisory techniques
- resolution: adopt Makoto's technique "The specific definition
of a word is provided at the bottom of the page. The internal
link from the word to the corresponding definition is also
provided within the page."
- resolution: adopt John's "inline definitions" technique
- L3 SC3
- ready for publication except for question about level (proposal to
move it to level 2 from level 3)
- L3 SC4 - previously agreed to combine with another SC (minutes from
previous meeting??)
- L3 SC5 - ready for publication except for question about level
(proposal to move to level 2 from level 3)
- L3 SC6
- ACTION:Kerstin to clarify 3.1 L3 sc6 failure
examples
- resolution: keep at level 3.
- ready to go out except for failure examples?
Guideline 3.2
- L1 SC1
- resolution: change SC wording to "When any component receives
focus, it does not cause another change of context." (added word
"another")
rationale: helps remove confusion people have about the initial
receipt of foucs - which is itself a change of context
- resolution: rename last item in common failures to, "failure do to
using script to remove focus when focus is received (in order to
remove visual indication of focus)
- resolution: change the beginning of the note associated with the
defintion of change of context to, "A change of content is not always
a change of context. "
- L2 SC1
- there was a lot of discussion on this one and no clear resolution.
this statement appears towards the end, "move this to L3 and add
failure condition to keyboard operation SC". check wiki for correct
wording.
- L2 SC3
- resolution:accept proposed definition of same
functionality: Items are considered to have the same function if the
outcome of their use is identical. For instance; a submit "search"
button on one delivery unit and a "find" button on another delivery
unit may both have a field to enter a term and list topics in the web
site related to the term submitted. In this case they would have same
functionality but would not be labeled consistently.
- ACTION: david will work on techniques and examples
for GL 3.2 L2 SC3
- ACTION: David to examine the use of the term
"label" throughout the Guide Doc and propose resolution
- ACTION: David, Alex, Gregg address the issue of
whether GL 3.2 L2 SC3 covers L3 SC1 and thus L3 SC1 can be
deleted
- L3 SC2
- resolution:accept John's proposed intent as the intent
for this SC, "The intent of this SC is to encourage design of Web
content that gives users full control of changes of context. This SC
aims to eliminate potential confusion that may be caused by
unexpected changes of context such as automatic launching of new
windows, automatic submission of forms after selecting an item from a
list, etc. Such unexpected changes of context may be cause
difficulties for
- resolution: accept Christophe's update for the second example, "An
"Update now" link or button on a web page to request a refresh of the
content (instead of using automatic updates)."
Guideline 4.1
Summary
of issues provided separately.
Guideline 4.2
- L1 SC1
- ACTION: loretta and gregg does 4.2 l1 sc1 need to
provide more information about where/how the alternate version is
provided
- ACTION: lorretta and gregg to look into adding the
phrase "at the same URI" instead of "is provided"
- ACTION: loretta draft proposal for intent section for 4.2 l1
sc1
- editors:
- resolution:don't delete 4.2 L1 SC 1
- resolution: delete the "titles" Sit. A * Sit. B
and leave the two techniques as options
- suggestion: an alternate version that supplies all
the same information and techonlogy
... an alternate version that supplies all the same information
and functionality
- resolution: add "and is as update as any
non-conformant content" to the end of the definition of Alternate
version
- when we returned to this a couple days later...
- resolution: adopt the following as the SC text for GL 4.1 L1 SC1:
If content does not meet all level 1 success criteria, then an
alternate version is available from the same URI' that does meet all
level 1 success criteria.
- L1 SC 2:
- resolution: change the sc 4.2. L1 sc2 to : Content meets the
following criteria even if the content uses a technology that is not
in the chosen baseline:
- editors:
- ACTION: lorretta and Becky will come up with
suggestion for 4.2 L1SC2 Techniques #2
- ACTION: lorretta to include Example 2 in her
revision action for 4.2L1SC2
- L1 SC3
- L1 SC4
- L1 SC5
- editors:
resolution: adopt John's proposed
technique that using HTML according to spec is sufficient to meet
this SC
- resolution: adopt Ben's proposed sufficient technique: Follow
accessibility API features that allow setting state and value
information.
resolution: change the benefit to
Ben's suggestion: Some users rely on their assistive technology
for their interface. This criterion allows them to do so."
- resolution: accpect Ben's proposal for updated intent: "This
ensures that users can use their assistive technologies to change
the states and values of all content that can be changed via the
user interface."
- resolution: accept new note in intent section: Note: Success
criterion 3 ensures that values can be read and this success
criterion ensures that they can be controlled.
- resolution: accept proposed note for the techniques section:
Note: In most markup languages, this functionality is provided
through the user agent. In programming languages, it needs to be
provided through support of accessibility features in APIs.
- resolution: move definitions to boneyard. Definitions were
inspired by content at http://www.w3.org/WAI/PF/roadmap/DHTMLRoadmap092305.html#properties
- ACTION: Gez and Gregg will propose new
definitions
- L1 SC6
- editors:
- resolution: add John's proposal - Suggest the
following for the Intent section: "The intent of this SC is to
ensure that assistive technologies can inform users when changes
have occurred within the content."
- resolution: put the general technique on the working group list
4.2 L1 SC6
- L2 SC1
- L3 SC1