LK chris made changes. shall we discuss?
BM yes, i checked out. let's discuss.
LK determine the purpose of a table. 5.1.B. Newspaper with headline with text, then leadline w/text. the headline is in a cell, the text in a cell below...top row 2 headlines in 2 cells. a layout table, yet text cells rely on headline cells. so the order is important.
BM isn't that layout?
LK yes but you have to worry about linearization.
WC but if linearize by col then would be all right.
LK WCAG says by source.
WC no. oh yes it does. i believe should be by row or column.
LK people shouldn't have to try to do more steps.
WC but if people really want the info. then they should be able to make multiple guesses.
LK it is suboptimal. it's gotta make sense when linearized by the source, per defn in WCAG. therefore cut and dry.
CR for your example LK, it would be wrong.
LK yes.
CR if you are using a table for layout it should be organized so it can be read row by row, so just one column of the table. a layout table should only have 1 column.
LK no. if you have a bunch of items and it doesn't matter the order you read them, then is o.k. If the headlines on the 1st column, then would be o.k.
/* HB joins */
CR so by source.
HB what about internationalization?
LK we're assuming a screen reader that reads cell by cell. we have to require that it makes sense when read in the document order. WC still disagree?
WC not sure.
@@WC & LK discuss offline what should be required by "linearization".
CR what else do we want in a summary?
BM if it is nested or not?
LK yes.
BM a technical description?
HB rows? columns ?spanning cells?
BM yes, anything other than row column type of table. for a user navigating it so that they have an idea what looked like visually.
HB assuming a DOM is available?
BM don't think we can.
HB most of that intrinsically described by DOM.
LK may be too much info. if you have nesting for layout purposes may not be important.
BM description as necessary to aid non-sighted user to visualize the layout.
LK in understanding.
WC goes beyond what required by WCAG. put burden on author, should be UA.
BM make any suggestions?
HB part that is uniquely created by author is what structure does not reveal. the intended content. the larger semantic in which this table fits.
CR is that the purpose of the table?
HB yes.
CR close to what the guidelines say?
WC reads from techniques.
LK i thought it was shorter, more like an alt than longdesc.
WC reads from HTMl 4.0
LK what about "title"? caption? summary? what are the differences?
HB summary could suggest that you have 5 income categories and 4 other types. therefore structure.
/* WL join */
WL how to caption and title differ? /* looking it up in "Raggent on HTML 4" */
WC /* reads from HTML4 spec (comparison of summary and caption). */
LK back to discussions of alt-text and longdesc. some users who are blind will say they don't want additional clutter. once you have a caption, you might not want or need the summary.
HB both are optional.
WL both are being recommended.
CR for accessibility we're recommending a summary.
LK but if we have a summary, need caption?
HB caption - table purpose. summary - omit that if in caption, and do a structure description.
LK any that read the summary.
WC believe home page reader?
LK reads in isolation, requirement on UA to read in sequence.
WC beginning to sound like a WCAG issue. should model after alt/longdesc recommendations yet not as stringent (alt always required, caption isn't).
HB right. simple table in a paragraph.
LK here's the relationship between our 4 income and 5 age categories...does no harm.
WL if it is the tooltip, and text, and... so what?
LK because people want minimum alt-text.
WL then have them set up AT with a feature that makes decision...
LK based on semantics.
WL i don't want alt for HR, or whatever.
@@ WC take TABLE summary, caption, and title issue to WCG.
WL's birthday! Happy birthday!!
LK evaluation: style sheet can be embedded in page itself.
WC STYLE element.
@@CR will check into checking for the STYLE element in the HEAD elements for Guideline 6.
/* lost rest of discussion .... here's WC's best recap...*/
suspicious: STYLE and LINK in HEAD.
not allowed STYLE in BODY - or is it just suspicious?
what about "style" attribute? does it cause accessibility issues or is it philosophical?
tools will be generating whether authors are aware of or not. also have issues with tools generating absolute positioning and font sizes. so what can we do about it?
how do we determine if a page is readable without a style sheet? will have to provide an author with a tool that gets rid of the style sheet then they determine if it is readable.
what about readable across browsers that DO support style sheets?
WL suggested a tool that would allow users to get a list of all styles defined and let them modify as they like. for example, class "clock" appears on LI and P elements. the user can modify how it is used...
/* WC notes afterwards as I clean up the minutes, this tool would have to include the cascade */
We will go to a weekly meeting.
@@LK will reserve bridge for 1 1/2 hours every week.
We will aim for first public draft by mid-February.
@@EVERYONE - review the document and post issues to the list.
@@WC track issues in open issues list.
@@WC and CR edit document as issues are resolved.