July 2, 1998 4:00 - 5:30 Eastern Standard Time
Gv: Gregg Vanderheiden (Co-chair and editor)
Wc: Wendy Chisholm (editor)
Cl: Chuck Letourneau (Co-chair)
Cmn: Charles McCathieNevile
Jw: Jason White
Dd: Daniel Dardailler
Gf: Geoff Freed
Short discussion re ideas for the Easy Read version of this which we will need to write as soon as this one stabilizes.
Jw: what do we see as the final output: three documents? - a table, a longer, smoother form, and a techniques document.
Cmn - if we have one document that is the untabulized form, followed by a table to summarize it,
Gv: followed by the techniques.
We have a great format developing but still need to figure out how to handle these tough issues. We have an idea and are looking for feedback and/or any other ideas. For convenience, the idea is in a separate memo titled "HOW TO HANDLE INTERIMS AND FUTURES."
One of the problems we still face in out guidelines work is how to handle the interim and future issues. It is just too confusing to say that people should use stylesheets for laying out pages when we all know they don't work that way with any browsers today. Putting future next to them is confusing and won't be accurate in 6 months anyway.
So we thought about building trigger points into guidelines so that they make sense both today and after the trigger point has been reached.
For example
LAYOUT OF PAGES
Once all of the major browsers support CSS-2 and the browsers are used by the majority of users, CSS should be used to control layout and presentation. Until then tables (to control layout) and bit mapped text (for special text effects) may be used with alternate accessible pages as necessary.
NOTES:
So what are your thoughts and suggestions on this approach?
Better than the past?
Good enough to address the major problem we had?
Got a better idea yet?
Cmn: using tables for layout is a bad idea - don't use them.
Dd: doesn't think tables are inaccessible - things decompose well in Lynx for instance.
Cl: but many people must use graphical browsers that do make
Dd: but people could use a proxy server. Doesn't like to ask authors to provide an alternative page when these other techniques are available.
Cmn: the provision of alternate pages is a last resort and should stay that way, but could recommend that page authors design pages that aren't dependent on positioning.
Gv: there is no accessible way to lay out a page and alternate page is a last resort because there is nothing in between.
Jw: the linearizing proxy should be mentioned as a technique that can be used.
Jw: also, as much as possible make sure that guidelines are not tagged as interim - only techniques.
Gv: that is the whole point of the table.
Gv: is the table continuing to evolve in the correct direction?
Cl: yes - this allows us to build any document we want.
Gf: agrees with Chuck
Gv: do we agree that stating "once something happens" you can do this, but until then, here are the things you can do? Rather than listing multiple past present and future guidelines?
Dd: thinks we need to find better words to describe that, but in general we are on the right track.
Cmn: agrees with this new style.
There was some discussion of bit-map fonts and how the guideline applies to it. Can CSS1 do everything that designers want? Not really. Bit map text is still useful. There was some discussion about the likelihood of full implementation of CSS2 and it seems to be problematic.
Gv: (as an aside) we have taken out that use of the css is required from the current guidelines.
Any wording suggestions for
Cmn: Tables in terms of layout are inaccessible and require an alternative to be available
Dd: thinks it is too strong. What percentage of people are we talking about before asking all the authors who us tables for the next couple of years to provide duplicate. Cant see being that radical without seeing how many people.
Cl: but aren't we providing guidelines that people can use if they want to make a site as accessible as possible? People don't have to, but if they want to, here is what you do. If a company doesn't want to do it, that is their decision.
Gv: but these guidelines may be used to determine what make a site accessible and be used to generate lawsuits.
Cmn: if we don't be radical, then we are saying "screw" the people who have to use graphical browsers with screen readers who can't use the linearizing proxy.
But isn't suggesting the linearizing proxy like giving an alternate page?
Gv: not really… it provides a different view of the same page.
Gv: is there any reason that we couldn't make a plug-in for a graphical browser
Gf: better to avoid plug ins - since there are already a zillion plug ins now, and plug for better design.
Gv: a plug in that could help with all the legacy tables that exist now, or wait a year for browser manufactures to incorporate something or wait for servers to put a script on their servers. We could write the plug in more easily than change people's behaviour.
Gf: is this plug in instead of advocating for change.
GV: no it is to fill the gap til the browsers change. If the browser is accessible to begin with, there is no problem- and that is our goal. In the mean time we need to fix Current browsers. There are lots of ways to make plug ins available.
Cmn: what is the roll out time for this thing.
Dd: this is a tool. We are already asking a priority item in User Agents to provide a linearizing tool. It is going to take time regardless to get solutions. Still not sure that table are evil. Simple tables are not good design, but not really inaccessible.
Gv: what ever the roll out time, it is quicker than changing attitude.
Jw: still thinks the guidelines should recommend the best practices and interim solutions.
Linearize=serializeThere is a split in opinion on Tables:
Cmn: strongly in favour of saying tables are inaccessible
Dd: strongly not in favour of saying table are inaccessible: incapable browsers are the culprits.
Cmn: Say that tables are not properly implement in a number of situations, and therefore people with screen readers have problems.
Gv: that doesn't help since we are only saying that the problem is the page author's to figure out, and not telling them how. If WE don't know how can we pass it on to them?
Jw: W3C should be sending a strong message to browser manufacturers to build things into.
Dd: even if someone uses CSS2 properly - there is no guarantee that browsers will allow the proper cascade sequence.
Dd: we have to take as much of the burden off the page author as possible otherwise we are doomed to fail.
Cmn: if we say the guidelines shouldn't be used to determine the legal accessibility of a site, that would be a good thing.
Three solutions:
Gv: Don't use tables doesn't work for tables used for tables (as opposed to layout)
Dd: but a table as a table is probably derived from a database structure, but it really is a table for layout.
Jw: but the header and scope attributes code the semantic information for a table
Gv: but those things aren't used in current browsers. So what do we do for all of the tables that are out there and for those writing tables for the next year or two to come?
Dd: is it easier for a page author to make a page accessible or easier for the end user to get an accessible tool? Who would win this case in a court.
Gv: asking people to provide an alternative view for all pages with tables would be very hard to do - unless we give them a tool.
Jw: be careful to distinguish between the guidelines and the techniques, The techniques be clear on the interim stuff.
Dd: separate the guideline that says we must use CSS2 for presentation. Make using a table a special case - if it can't be read left to right, then you will have a problem. Make special cases for the really inaccessible uses of tables. Don't vilify the acceptable (even if problematic) use of tables.
Gv: Wendy brought up the concept of usability versus accessibility. How unusable does something have to be before it is inaccessible.
TABLES:
Jw: in the HTML spec, there was some discussion of some algorithm the User Agent would rely on to determine what the header would refer to in a table.
Can we determine any situation in which it would fail.
Dd: last message and previous message discussed tables that work with the algorithm. Dave Ragget had some input.
Gv: will remove this from discussion until we can review the material out there and discuss on the list. LONGDESC:
Jw: the way to consider it is decide how much content (maximum) we want in an ALT attribute, then basically say if you need to write more than this, it should be taken to a LONGDESC.
Jw and Dd: A sentence or so would seem long enough for alt-text. If more than that is required, then a LONGDESC is required.
Gv: still to decide what TITLE is all about, and how best to use alt.
Your recording secretary had to leave the meeting at this point (5:30 EDT)
There are a number of places where we need to closely cooperate with UA group. For example, LONGDESC and ALT text handling. What are all the areas? How best to cooperate.
Gv. areas for coop that we know of are
- LONGDESC and D-LINK
- ALT text (esp for decorative and spacers etc).
- TITLE
any others
Dd: REL
Gv: ok post any additional to the list
We need to get to work on the Techniques document too. We would like to begin this dialog and harvest any ideas people have.
Gv: this will be focus of the next teleconf (and cleanup on current topics)
July 9, 1998, start time 5:00 Eastern
The main topic of discussion will be the Techniques part of the document.