WCAG WG weekly

21 Apr 2005


See also: IRC log


Michael_Cooper, John_Slatin, Yvette_Hoitink, Loretta_Guarino_Reid, Wendy, Matt, Bengt_Farre, Christophe_Strobbe, Becky_Gibson, Katie_Haritos-Shea, Tim_Boland, Gregg_and_Ben, JasonWhite, Mike_Barta
Makoto UEKI, Neil Soiffer, WATANABE Takayuki, Andi Snow-Weaver, Roberto Scano
John, Gregg
Michael, Yvette, Becky_Gibson


Agenda Review (John - 5 minutes)

js: harvest feedback on issue summaries of 2.4, 1.3, 4.2, 1.1
... get stuff on table for people to incorporate into revised proposals
... then look at planning framework

TTF Update (Wendy - 5 min.)

<wendy> http://www.w3.org/2005/04/20-wai-wcag-minutes.html

wac: discussed Becky's categories of scripting techniques
... Becky has more action items
... discussed planning framework
... actions to work out details
... assignment templates - for people to use as they work on proposals
... discussions on <object> issues
... technique using <link> from PF group (based on DHTML roadmap)
... more action items to investigate
... discussed structure of guide doc, re proposals sent last week
... more work to do on those to harmonize and re-propose

issue summary on guideline 2.4 (Yvette- 25 min.)

js: reminder, just take questions, and take comments and responses, goal not to close today

yph: found items to close, some that need small amount of discussion, some proposals for new SC, and some proposals for deletions
... a major problem is overlap between 2.4 and 1.3

1.3 is separate structure from presentation (or behaviour), 2.4 is structural stuff for navigation

yph: 434 propose to close

bbc: fact we have a level 1 SC doesn't necessarily deal with overlap with 1.3

yph: some suggestions to make L3 items L1, propose to postpone until those are handled

gv: artifact from back when we designated as Core or not, therefore can close this as overcome by events

bbc: not opposed to closing issue, just want to be sure of rationale

js: objection to closing on above rationale?

yph: 829 move linear reading order to L1
... now reworded as re sequence
... related item we might want to delete - issue 1441
... can't test if sequence matters (author decision), and also covered by 1.3, therefore remove SC

js: 1 proposal to promote, 1 to delete, discuss

gv: current wording doesn't make sense, not sure why necessary
... need to be sure whatever we do is conditional re sequence, because much content can be read in many correct ways

wc: relates to 1214 and 1391
... 1391 is programatic determination of sequence is too vague, maybe needs to be always programatically determined

wac: perhaps sensible keyboard navigaiton overlaps

wac; 1214 is skipping groups of links, also relates to order making sense

wac: we need something at level 1 but could make it more broad

js: example of online newspaper with sidebars etc. in general techniques
... intent not to assume all conditions but to deal with when screen readers make gobbledegook
... perhaps wording to clarify that needed

tb: concern of objectivity of "meaningful" - author and user may disagree
... can it be objectively evaluated?

js: can be evaluated by human

yph: 1214 promote to L1 for harmonizing with Section 508
... is harmonizing something we want to consider?

gv: propose we hold off because one of the WAI metagroups is discussing

wac: if we agree to move navigating items in sequence to level 1, this really just falls into techniques so we can remove SC
... need to be sure we discuss grouping things, then discuss navigating in sequence
... some ohter changes outlined in a post re this

js: discussion of <link> to provide such features another technique, supporting Wendy's position

gv: not clear on Wendy's proposal

js: discuss on list

yph: progressive complexity - easy to understand summary, then other stuff
... was proposed to go under 2.4
... bug 1132

<ben_> http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1132

js: should be addressed by a proposal working on

yph: 1137 increase prioirty of divide blocks of information in to manageable units
... 2 SC for this - text as paragraphs and hierarchical sections

<ben_> http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1137

yph: perhaps we should have a more generic version
... re need to divide blocks of info into manageable units

gv: recursive - when you divide blocks you still have blocks that need to divide. Need a divide when "too large" and how do you define threshold.

js: work on 3.1 might be relevant
... relative to size of task user has
... exist generally accepted ways of discussing that stuff, will send to list
... may be advisory too

gv: many of the things we look at we "harvest out" into advisory techs

lgr: agree not only text that needs structure, but concerned re house example
... zoom in vs explore

yph: yes, need manageable

js: yvette should write up as functional outcome, then we can look at techniques to achieve, e.g., separate steps, zooming, etc.

4.2/UAAG summary and issues (Loretta- 25 min.)

js: process pause - we want to get to a proposal, which should allow us to close bugs

gv: may need to modify proposals for some things based on discussion, things too controversial might need to be re-raised

lgr: 4.2
... summary from subgroup work in overview message
... difference between web application and user agent
... based on that distinction that Wendy wrote, we tried to walk through UAAG level 1 to see what was involved and see if WCAG already covered that or things needed to be added
... feedback anyone?

gvdh: is the distinction in the post?

js: listed in the agenda, includes Wendy's message with distinction between web application and user agent

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

js: sorry for the URL mix up, wrong URL was in the agenda

lgr: is definition of web application appropriate for what we want with this guideline?

js: that's two questions: 1. definition of web application clear and accurate? 2. is this appropriate for our purposes?
... anyone have a different definition for web app?

gvdh: do web applications have interface controls? 4.2 is meant to handle the included interface. Example: flash
... we never said that it _was_ a user agent, just that it has interface controls so we said rather than make our own rules we refer to UAAG

wc: we were looking at UAAG because we were looking at interface. However if you look at our guidelines, we actually cover interfaces pretty well in our guidelines
... main issues: name widgets, make sure widgets can be accessed, provide role and state information
... we matched all the UAAG to WCAG 2 criteria and realized that there are places where authors need to provide the input the user agent needs to provide the interface
... there are some additions we need to make, without re-inventing the wheel of UAAG.
... interface _is_ covered by our guidelines, with some possible additions

js: confirm what wc said
... there are analyses of how UAAG relates to WCAG

bg: Questions about Wendy's message about web app and user agent
... I'll get back to that later

jw: Agree with wc
... in analysis it became clear we couldn't just refer to UAAG
... it's not possible to conform to UAAG with web content
... we need to find out what's missing from the guidelines for user agents to work with

bg: I didn't get some of the examples Wendy gave like the Javascript one.

wc: examples were to illustrate web applications that were not user agents

<wendy> what the author needs to provide in the delivery unit so that the user agent can generate an accessible perceivable unit

gvdh: if I understand correctly, most of that is already in our guidelines
... so rather than sending people off to UAAG, just include what's missing in our guidelines
... so we suspend the reference to UAAG until we figure out what's missing
... need to make sure people creating web applications put the right stuff in so they're accessible
... make sure all the information is available to screen readers

js: that's exactly what the analysis calls for
... analysis tells where in our guidelines we need to specify that

bc: In the UAAG analysis there are examples that talk about requiring that things be available programatically
... confused by what was meant by some of those f.e. "require to determine background images programatically"

lgr: the idea is to make sure that no matter the form, the user agent will be able to get at the information
... if it's HTML source, that's programatically available to the UA
... it's a way to say that the source expresses the information about these relationships.

bc: that helps a bit, I can see that there are cases where it's more difficult to distuinguish between foreground and background
... I can see where you're going

bg: Issue I have with this (will post) is about requiring ATAG for web apps that allows content generation
... for example: mail input web app that would require asking for alt-text
... scares me as web app developer

wc: only web apps that involve creating content that is meant for the web would need to conform to ATAG
... hairy issue: for example, our IRC client logs to the web, so would our IRC program have to confrom to ATAG?
... we could say "if your app generates web content, go to ATAG"
... doesn't clarify when web content needs ATAG or WCAG

bg: an e-mail application could generate web content too, but you mean specifically web content generating applications?

wc: Yes, blogger for example

bg: I'll post my example to the list

tb: ATAG meeting next week. I'll take it to that group.

mm: from the ATAG perspective everything is well defined already. I'm missing what the grey area is

wc: the current def of AT doesn't exclude content that isn't necessarily meant for the web
... when we participate in mailing list, we are generating web content

mm: not true, the W3C tools are creating web content. They are taking content not meant as such and creating web content from it. IRC client is not an authoring tool

js: Loretta, can you make 4.2 proposal by Tuesday?

lgr: SURE!

js: There's a number of important messages about 4.2. PLEASE READ THEM

lgr: Would like comments by end of day Monday

issue summary on guideline 1.1 (Wendy- 25 min.)

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

wc: when started 1.1 revies serveral issues about definitions
... depending on defs. SC can mean very different things
... started with definitions to get grounded and felt first SC is most contentious and affects baseline
... main ques. is if we define text content as ...... and functional text content as ..... (see post)
... also proposed defs for content
... don't want 4.2 to morph into just how to label widgets

gv: separate out non-text content is anything not rep. via unicode characters - feels like good def - are there any concerns?

bc: what about ascii art?

gv: is ascii art represented as string of unicode characters?

wc: going to need a sub def for each type on non text content
... functional non-text, non-text to create a sensory info and .....
... ascii art is used to convey info so I think def holds
... 3 text def: functional non-text, not-text to convey info; and to convey sensory exp.

gv: have to consider spatial arrangement - will post a def

jw: issue of meaning of content; ordinarily content in delivered unit is considered content; it is not always a stream of ordered unicode characters
... not all of those may be presented - we need to make a disctinction about what is content that is presented to the user
... need to be specific as to what content wcag applies
... example is a pdf file structure of the document is not represneted as seq. of unicode characters even though the text is
... don't want to req. the structure to require text alternative

cs: concerned that req. unicode is controversial
... issues with Japanese and chinese in particular

wc: to address CS will take action to check with WT and Makoto
... but thinks unicode should cover

js: but we are not req. unicode, right?

<wendy> ACTION: wendy to check with makoto and takayuki other w3c people. [recorded in http://www.w3.org/2005/04/21-wai-wcag-minutes.html#action01]

wc: correct; document does not have to be documented in unicode but must represent unicode character
... non text content refers to what is in perceivable unit; content refers to what is in delivery unit
... will tweak defs

gv: I think we are req. unicode- if not what else are we req text to be in?
... if not req. unicode then what is our def. of text?
... jason's pt is excellent - talked about separating structure of info from the info
... structure is content so can't define all next content to incude;
... what do we call content that is not part of structure?

lgr: i think we are saying that unicode rep of text should be programmatically determined

gv: want it to be in unicode when AT accesses it; can be encrypted, compressed and UA would pull it out
... has to be in fashion that when it goes thru UA it gets presented as unicode

lgr: thinks wendy's def that talks about any encoding can be used but must be able to be mapped into unicode

gv: but mapping is issue - are we req. all UA to convert everything to unicode
... have Vander
... have VanderEncryption so now UA is req. to map that to unicode?

lgr: you must provide mapping/apis

wc: unicode is very "general" term - there are several encodings you can use to get to unicode characters

gv: but lgr was going further saying any coding

lgr: think misinterpretting programmatically determinable
... suggest taking off list

gv: wendy has discovered imp. whole

wc: think some of issues we are discussing with tweaks from JW that defs proposed are still heading in right direction

gv: see Jason's issues as biggest - use of word content

wc: we can use what is in delivery unit vs perceivable unit to help clarify

mm: disagree that structure is info - structure is meta info.
... if have a doc with only structure there is no info being conveyed

gv: structure is not information

js: markup is information about the document - that is one kind of info we are trying to preserve across changes in presentation
... markup is meta info about the content and how it is organized so we need to be able to talk about both that and the material that is not pure structure
... but is presenting substance of what we want users to interact with

bc: want to ask about the labeling and flickr app
... curious of how baseline ques. fit in - right approach to force labels for each function
... if my baseline includes support for flash I assume flash player deals with desc. of information
... with it

wc: each widget must be labeled for the baseline that assumes web apps; for lower baseline would provide the alternative mech to provide functionality

gv: if have flash that has controls and exposes them to screen rdr then they would have labels
... if controls are not exposed to screen reader then would have alternatives
... all the way down to the widget level there is text
... describe the widget at the level that it occurs (editor didn't capture this very well - sorry)

wc: thinking that role and state stuff fits under 1.3
... 1.1 labelling the function, - keyboard access; 1.3 - behavior

js: please read and respond to Joe Clarks issue summary - deals with GL and not SC so will ask him to address SC in relation to issues he summarized

wc: can you post what you just said about 1.3 and role and state

<wendy> ACTION: wendy suggest role/state as part of new 1.3 (ala joe's proposal) [recorded in http://www.w3.org/2005/04/21-wai-wcag-minutes.html#action02]

js: more comments or concerns about info already discussed?
... any objections to Wendy pursuing her approach on 1.1?

gv: think it is good as it is exposing old issues - so think it is worthwhile continuing the exploration
... but a bit worried about combining 4.2 into other places things will be too confusing - only a mathematician can understand
... don't want it to be too confusing because defs are so precise- may need plainer language

Looking ahead: Proposed planning framework

js: each thurs call will discuss 4 issue summaries and/or proposals
... 2 step seq. first call will discuss and raise concerns about proposals sent to list two days earlier

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

js: discussion will feed revised proposals and issues summaries to be sent to list on following tues
... for hopeful resolution /consensus on following thurs
... WC is putting this into an app and will be posting the calendar into planning section of WG site
... is dynamic plan so we can get clear representation of what happens when we fall behind
... hope this keeps us mindful of role we play and implications of missing deadlines
... so as soon as you know you are going to miss a deadline please let someone know so we can plan and adjust
... know this sounds very corporate but needs to be said
... want to thank all who are working hard and participating

gv: if any hope ot getting to end need to operate in such a fashions
... need to continue momentum to keep making progress - reiterates thanks

Summary of Action Items

[NEW] ACTION: wendy suggest role/state as part of new 1.3 (ala joe's proposal) [recorded in http://www.w3.org/2005/04/21-wai-wcag-minutes.html#action02]
[NEW] ACTION: wendy to check with makoto and takayuki other w3c people. [recorded in http://www.w3.org/2005/04/21-wai-wcag-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.122 (CVS log)
$Date: 2005/04/21 21:58:49 $