WCAG WG weekly telecon

Agenda overview

<wendy> js: goes over the agenda

<wendy> js: there are a lot of proposals to cover. propose that we don't discuss examples or benefits because they are informative, thus domain of editors (per previous WCAG WG discussion/resolution).

<wendy> js: if you have comments about examples or benefits, please send to list and editors will address on list.

Techniques Task Force update (Michael, 5 minutes)

minutes from yesterday's telecon: http://www.w3.org/2005/04/27-wai-wcag-minutes.html

mc: we assigned techniques/test cases yesterday to people for 1.1, 1.3, 2.4, and 4.2
... will do issue summary and proposals for all techniqeus and test cases that are related.
... follow similar process to thursday calls.
... by monday will have issue summaries for the first batch.
... trying to stay in synch with the guidelines work.

<Michael> http://www.w3.org/WAI/GL/WCAG20/WD-wcag2-tech-req-20050426.html

mc: techs task force ppl will coordinate with the folks who did the issue summaries for each guideline.
... did some work on requirements for techniques and checklists
... more actions yesterday for clean
... baseline is a big issue. will talk next week about how it effects techs.
... also discussed becky's mappings of script techs to guidelines/success criteria. about 1/2 way through discussion.

4.2 Proposal and summary (Loretta, 25 minutes)

js: of the 6 points related to the proposal, list discussion has focused on item 6 (new SC for 1.3), and 1 (defn of baseline).
... would like to get people's concerns. begin w/people who have been involved in the discussion. then discuss proposal.
... anyone who has already commented on list wish to clarify or add to anything they've said?

gv: proposed removing the guideline because it is covered by the defn. Howver, the defn is full of success criteria.
... it has "must" and "may" which is SC language.

lgr: what are you refering to?

gv reads from loretta's proposal, "technologies that must be supported..."

lgr: this is trying to defin what baseline means.

gv: in the rules of writing standards, must and may can not be in definitions.

js: the 1st sentence contains a definition, some of the other items could be treated as SC under a rewritten 4.2.

gv: 4.2 was to ensure that user interfaces are accessible. however, not sure how a definition can substitute for a requirement.

lgr: issue is "will the guidelines require a baseline or not?"
... my analysis assumes we are moving baseline out of guidelines, but that a BL does exist.
... this is an attempt to capture what we mean

gv: if we don't set the baseline then it can be anything

lgr: someone will have set what we hope is a sensible baseline

js: perhaps we should look at the other 5 parts of the proposal since they all interact.

gv: at this point, the defn needs to be looked at. haven't figure out if we have achieved what we wanted to. agree, should walk through the rest.

jw: agree with all 6 of the proposals. also agree with gv's comments.
... a couple ways to approach: 1. we're letting devs set baseline. also giving them guidance about setting. can't do in defn of baseline. the reqs either belong in conformance (since apply to all guidelines) and determine how conformance is judged or belong in a rewritten 2.3 (?). this effects how you apply all of the guidelines. therefore, don't think it belongs in a guideline.
... needs to be clear that it does apply to the whole doc. perhaps revised 4.2, although conformance probably better place.

asw: should go in the conformance section

lgr: felt that were 2 parts of 4.2 that were covered: 1. moving baseline and UA assumptions out of guidelines. 2. creating UI elements (and their accessiblity)
... feel that the group focused on 1. then went back to look to ensure covering 2.
... think it's easy for us to get lost in the sea of all things we were trying to accomplish w/this analysis.

mb: defer. agree w/other points

js: broaden scope to talk about the other components of the proposal.

<scribe> ACTION: andi rewrite defn of baseline and conformance section

gv: re: conformance section - "need to know what...by user agents" should be "accessible user agents"
... if there is potential for wcag 2.0 to be adopted as iso standard, should pay attention to iso rules.

js: iso rules seems like an editors thing.

gv: issue with referencing a non-normative document (see "WCAG 2.0 Guide to...")

<scribe> ACTION: editors looks into iso rules and referencing non-normative documents

gv: there are several open issues related to conformnce.

js: proposed SC for 1.3 - concerns about what can be changed progrmatically or if should be limited to elements.
... discussion was that should go beyond element to all content.

gv: should check with greg lowney re: role question.

gv reads latest proposal

Any change made to content via the user interface, including changes to state and value, can also be made

programmatically

jw: role, state, and value deserve definitions.

js: if defined in xhtml 2.0 spec or uaag, should use those defn.

gv: should considerif we need defns or not.

<scribe> ACTION: jason check for definitions for role, state, value

bg: role is an attribute, are we saying have to change all attributes programmatically?
... i can write a javascript function to change the role. is that the user interface?

gv: yes. and it should be operate programmatically.

bg: confused as to what we're really trying to say.
... i can change any attribute. do you mean things that the user agent UI can change or ??

js: a user interface element in the content.

gv: most people who are writing in HTML are going to have no idea what this is refering to.
... also, if writing in HTML don't have to worry about. doesn't apply to the author unless the author is creating their own interface.

gv: thinks the requirement is to be able to operate the interactive element programmatically

<scribe> ACTION: Gregg work with Loretta to rewrite proposed SC for 1.3

js: will wait for Gregg to post questions and for Andi, Gregg, and Loretta to complete today's action items before consensing on this proposal

1.1 Proposal and issue summary (Wendy, 25 minutes)

<wendy> http://lists.w3.org/Archives/Public/w3c-wai-gl/2005AprJun/0262.html

<scribe> ACTION: Loretta to collect proposals and comments on 4.2, change proposal, and re-post to list on Tuesday, 5/3

wc: Becky concern about form controls that have an event handler attached to them

<wendy> related to, "Any text alternatives are explicitly associated with the non-text content." added a note

wc: note added about explicitly associating text alternative with non-text content. Expecting comments. Didn't get any

js: did not interpret this as requiring a transcript for multimedia
... definition of multimedia we have been using in our discussion has excluded audio only and video only as multimedia

<wendy> current defn: multimedia For the purposes of these guidelines, multimedia refers to combined audio and video presentations.

js: disagrees with note under Level 1 SC 2 - don't think this requires a transcript

gv: current wording does require transcript

wc: 1.2 is about synchronized equivalents for multi-media, 1.1 is about the text alternative for non-text content

js: says equivalents have to be synchronized

in 1.2

gv: still have something to do for 1.1 Level 1 SC 2

js: have to decide if we want it to include transcripts or not

gv: what is label in Level 1 SC 1

wc: propose changing "label" to "text alternative"

gv: if I have a Web camera that is pointing at the water level in a reservoir - have to have text alternative or have to have another place where I talk about the water level
... if want to provide image of what is outside to staff inside, put the image on a separate page and exclude that page from teh conformance claim

wc: only have to provide a text alternative that describes the purpose of the "outside image"

gv: then a videoconference would only have to have a text alternative that says "displaying what is being written on the board"
... don't want to say this is accessible because it's not

jc: think SC covers the quirky case of a Web cam
... in the case that GV just described, presenter has to describe what they are doing just as if they were on stage
... should concentrate on the big problems we need to solve rather than worrying about people's Web cams

as: asks Gregg, are you trying to say that Web cams don't have to conform

gv: Level 1 conformance to guidelines doesn't say anything is "accessible" - just says it has met a certain degree of accessibility
... one of the reasons to cover in SC 6 separately is because it bubbles up. Wanted to make it clear that Web cams should be handled separately.
... if it's important that the Web cam information be conveyed, it will have to be conveyed another way
... proposes that we accept the new language but log 2 bugs against it
... bug 1 - not clear that we intend to require a transcript for all multimedia at Level 1

in reference to Level 1 SC 2

gv: bug 2 - in Level 1 SC 3 thinks "describe" is not testable enough

"how to" can be described in techniques but not "how much to"

js: also have some issues with definitions: unicode and non-text content
... ASCII art

wc: 2-dimensional arrangement

gv: what about emoticons

<wendy> joe reads: ASCII art, an artistic medium relying primarily on computers for presentation, consists of pictures pieced together from characters (preferably from the 95 printable characters defined by ASCII).

<wendy> http://en.wikipedia.org/wiki/Ascii_art

<joeclark> Smileys can be marked up with abbr. For the record.

jc: ASCII art, an artistic medium relying primarily on computers for presentation, consists of pictures pieced together from characters (preferably from the 95 printable characters defined by ASCII).

mb: emoticons are not a big issue because they are so small

jc: Smileys can be marked up with abbr. For the record.

<joeclark> "ASCII art uses (Unicode) characters as a medium to create an image."

<wendy> "consists of pictures pieced together from characters"

gv: should simply use "pictures pieced together from characters"

jc: "ASCII art uses a sequence of (Unicode) characters as a medium to create an image."

js: delivery unit definition is plain language paraphrase of the DI WG glossary definition
... proposal is to use the DI WG definition in the glossary and provide the paraphrase additionally

accept pending Wendy's review with DI WG

gv: thought explicit association could be in text - doesn't have to be programmatically associated
... what is in the note should be in the definition
... that's the note under Level 1 SC 5

js: have to decide if "explicitly associated" means programmatically determined
... comments should be posted to the list

non-text content

bg: have a problem with non-text content - are UI widgets non-text content?

gv: definition excludes them

jc: aren't there some elements in HTML that are quasi-behavioral - form elements and buttons
... should be covered by "use DHTML correctly"
... trying to clarify cases that would break proposal

jw: wants widgets and UI controls to be covered somewhere besides 1.1

js: thinks widgets could be covered under either the current or proposed 1.3

wc: should delete Level 1 SC 1 or change it to say "for IMAGES that are functional"

gv: could it have been meant to apply to image maps? if so, can these be covered in 1.3 too?
... Joe's comment about behavioral elements is interesting. Maybe 1.1 is meant to only apply to presentational elements that don't have behavioral aspects

wc: cannot rework proposal by next week

js: how would we rewrite 1.1 to logically exclude widgets?

jw: proposes add label association to 1.3 in addition to role and state

<scribe> ACTION: jason will post proposal to list

consensus to accept definitions for perceivable unit, text, text alternative, and unicode

2.4 Proposal and issue summary (Yvette, 25 minutes)

js: will not discuss examples as they are non-normative

<wendy> http://lists.w3.org/Archives/Public/w3c-wai-gl/2005AprJun/0247.html

<wendy> http://lists.w3.org/Archives/Public/w3c-wai-gl/2005AprJun/0169.html

js: propose we accept proposal to close issues by explanation to authors
... hold off on 2.4 and 1.3

wc: face to face will be week of June 13th in either Brussels, Venice, or London
... expecting to finalize in the next few days
... and will send something to list
... if in Brussels will only be 4 days, not 5
... assume people prefer Monday through Thursday