See also: IRC log
css techs draft: http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-CSS-TECHS-20040615.html
1.8 Conveying information through multiple means (not just color)
more of a general technique?
can user agent figure out color effects and present meaningfully?
as written, this technique does not mention css unti last bullet.
display: hidden has variable support in screen readers.
... none also has some support issues
<scribe> ACTION: wendy delete css:1.8, tom paste to general techs
<scribe> ACTION: wendy to delete css:1.8, tom paste to general techs
<scribe> ACTION: wendy to delete css:1.8, tom paste to general techs
1.9 Using relative units of measure for properties that need to change
this stays, but needs to be adjusted to sync w/defns of "relative" and "absolute" in css spec.
could map to 1.4 level 1 SC 1
1.4 is about contrast
users *do* have access to technology. reason for this is so that the user can increase font size and content reflow.
what about guideline about "transform gracefully"? (have received public comments asking for)
could 1.4 be generalized to cover visual presentation?
i.e., there are other font-related guidance that people have suggested we cover. e.g., JIS and choosing readable fonts
people can change fonts w/relative ease, but changing units of measure is harder to do.
<MichaelC> ACTION: Michael approach WG about a "transform gracefully" guideline under Principle 1 (borrow elements from 1.4)
<MichaelC> action 2 = Michael and Tom approach WG about a "transform gracefully" guideline under Principle 1 (borrow elements from 1.4)
1.10 falls into same category
1.11 Creating stylized text with CSS rather than using raster images
<scribe> ACTION: wendy and tom look at emphasis discussion and try to get on a thursday agenda
does "Any information presented through color is also available without color (for example, through context or markup or coding that does not depend on color). (Level 1) " apply to this one?
primary reason: want text available as text
isn't that the essence of, "Any text that is presented over a background is electronically available so that it could be re-presented in a form that allows the text to be distinguished from the background. (Level 1) " ?
a list apart article on text (takes plain text and converts to images on the fly)
1.12 Formatting and positioning of text
this covers positioing/layout tables?
and relationship w/using structural relationships
e.g., in HTML, use the header element and then style with css)
<scribe> ACTION: wendy break 1.12 up into multiple techniques then return to mapping
<scribe> ACTION: wendy to mark techniques as being general css or related to specific technology (e.g., html)
1.13 Text style effects: case, shadow, decoration
<scribe> ACTION: wendy break 1.13 up into multiple techniques then return to mapping
1.14 Creating rules and borders
at a minimum, separate into 2. since outline and border are very different
ties in nicely with 1.8
"They also end with the phrase "End example", but that phrase is hidden by default with 'display: none'."
if you are using border to denote structural section, then use text to show that - IF a structural element is already providing the info
also have to be careful not to overdo and specify when and which elements
<scribe> ACTION: break 1.14 into at least 2 techniques. tie in w/generating text IF structural element isn't already providing info (careful about not overdoing - optional?)
2.1 Text equivalents for content generated by style sheets
use media types to produce contet
isn't this saying the same thing as the other task? can we combine them?
If it is a background image, does it need a label? There is no exception in 1.1 for background images. Also, is there a way to "explicitly associate" a text equivalent with images included via css?
it's at odds w/1.11. using image replacement, could generate text equiv - although image and text not show at same time
for screen reader media type use text instead of image
this tech ought to be saying, if something important being include via css, either not include via css or describe in the html somewhere
until user agents support with this?
was reading as, "text equivalents for images generated by css"
yes, at odds w/1.11 (b/c there we recommend generating content to help indicate structure)
perhaps divide into 2: those things w/generated content that we recommend, 2. those things we are concerned about (although not banning, but saying, if you do, beware of xyz)
if using FIR, constraining size of text to appear in place of image. if turn off image, could resize text but could be in a tiny window.
<scribe> ACTION: wendy explore issues related to css:2.1
<scribe> ACTION: wendy delete css:2.2
2.3 Providing contextual clues in lists
this should be covered by the assistive technologies
useful for very old UAs, thus deprecated
similar to tech for generated content, but specific to lists
ALA article about generating hotkeys for links
real world exmaple (of this markup for lists)
<scribe> ACTION: wendy to mark css:2.3 as deprecated
3.1 Creating layout, positioning, layering, and alignment
duplicate of other?
other one specific about text
how split apart?
have separate techniques and then one overall technique that pulls them together
<scribe> ACTION: wendy cut 3.2: Null alt-text, michael paste into html
3.3: Providing good structural markup for graceful degradation
general or and relationsihps w/use of structural elements
and/or discuss at F2F re: checklist, afterwards discuss dtd
<scribe> ACTION: michael, ben, wendy ensure and/or relationships discussed at F2F and follow-up afterwards to encode
3.4 Scripting and style sheets
multiple and relationship
3.5 Using ACSS to create auditory presentation
If the audio-contrast guideline said something about the ability to turn sounds off or user control of styling sounds, then we could link to a success criterion. As is, linked to guideline but no criteria.
state of ACSS?
in 2.1, aural style sheets moved to an appendix: http://www.w3.org/TR/CSS21/aural.html
in css3, likely to reference SSML and other work by voice browser working group
css3 speech module: http://www.w3.org/TR/2003/WD-css3-speech-20030514/
"This draft describes the text to speech properties proposed for CSS level 3. These are designed for match the model described in the Speech Synthesis Markup Language (SSML)."
<scribe> ACTION: wendy to mark 3.5 as a future technique - placeholder. ref css3 speech module.
3.6 Access to alternative representations of content
which success criterion does it map to?
related to text equivalents to reduce cog load?
<scribe> ACTION: wendy to modify editorial note for 3.6 to capture issues and use as placeholder.
3.7 Media types
what maps to?
technology according to spec?
4.1 level 1
what about "separate structure from presentation?"
<scribe> ACTION: wendy to update mapping for 3.7 (map to 4.1 and sep struct from presentation)
<scribe> ACTION: wendy to review david's end-to-end to look at mappings
5 minute break. when return,
<sh1m> People involved in end to end
<sh1m> Wendy, Jenae, David
<sh1m> David:Use the end to end to see where we are overlapping, or do we have something in one document we aren't saying in another.
<sh1m> David:Putting them side by side is good for drawing comparisons you wouldn't see normally
<sh1m> Michael:Hard to do all the end to end in one session
<sh1m> David:It best at a one of a time thing
<sh1m> Tom:Doing them one a time especially with the guidelines as a baseline is good for getting them in line
<sh1m> Tom:Is this something that needs more structure in the agenda before we can approach it?
<sh1m> Michael:Shawn is on the call it would be great to have her thoughts
<sh1m> Shawn:The biggest thing is progressive disclosure
<sh1m> Shawn:A lot of the things, traffic cop, for example is good for step through.
<sh1m> Shawn:Getting presented with so many options when 'all I want to do is make my table accessible'
<sh1m> Shawn:A lot of people will print out, so we need to be aware of printing
<sh1m> David:What about the different use cases, what do people find confusing?
<sh1m> Shawn:Were you thinking of all of this at one time or one guidelines' worth?
<sh1m> David:They can scroll down to get what they want
<sh1m> bunch of people being loud in a shared office
<sh1m> Shawn:Generally people are going to need one little bit at a time, even one guideline
<sh1m> Shawn:Even the end to end is tough
<sh1m> David:The end to end is an internal thing
<sh1m> MichaelC, can you bust me in :P
<sh1m> I can't unmute without all this background noise
<MichaelC> yeah, just a minute
<sh1m> David:The end to end is for internal mapping from the techniques to the guidelines, and see it all side by side
people that are looking for html techniques will be primary people, as such many of them will want to get there right away w/out seeing other things.
versus, people who are using other technologies may be willing to search harder
"traffic cop" will not be the only means of interacting w/the resources.
it is *one* interface
if someone wants to go directly from success criteria, to techniues, they should be able to do that.
in wcag 1.0, have checklist of checkpoints and from that go to techniques.
perhaps at top of guidelines have two links: contents | examples and techniques
<Zakim> shawn, you wanted to say need the overview
need: ability to get the big picture
when teaching people about wcag 1.0, had a graphic that showed relationship between guidelines, checkpoint, techniques (gateway), and html techniques
many people had not realized there were so many pieces and how they connected
important to do up-front
<sh1m> wedny: presented at the www2k4 included a graphic about the big picture which was similar to some of david's work
<sh1m> wendy:Highlighting the links to the techniques documents from the WCAG20 document
<sh1m> Wendy:We have talked about linking from each success criteria, but we also need a bigger link from the top
a single page that contains all techniques for a given success criterion, doesn' thelp the user who wants to know "how do i make my form accesible?"
those are 2 different use cases
are we going to meet both of them?
primary use case: how to fulfill the guidelines
get that from table of contents in html?
depends on how it is written. techniques for wcag 1.0, techniques were in different places.
and, no index
should absolutely look at different use cases. however, don't have a different traffic cop for each use case, but can we create one primary interface that will work for multiple use cases?
need "search" to do that?
have the one page approach, but also an index at end of each page? a set of see alsos? cross-references? list of questions related to tasks to help create big picture?
since wcag 2.0 is not html-centric, harder to construct the "how to make forms accessible."
gateway as index into techniques. i.e., techniques are grouped by task/element
perhaps atomic techniques and then an overall technique to tie them together?
"by criteria" view - checklist satisfies?
<MichaelC> ACTION: Ben work on "by criteria" while working on checklists
<MichaelC> ACTION: Shawn and Wendy expand some of their ideas
<scribe> ACTION: wendy to rework image (w/shawn's help)
<scribe> ACTION: wendy to think about grouping techniques and tasks in css techniques
next week: review action items from last week
Deprecating layout tables
<scribe> new html draft
traffic cop related aciton items
next week: action items from last week, layout tables, end-to-ends