On the phone: Wendy, Loretta Guarino Reid, Ben Caldwell, Jason White, Bengt Farre, Jon Gunderson, Preety Kumar, John Slatin, Avi Arditti
On IRC: bazz, JRGOut, Zakim, PatBertin, bengt, mvittoria, wendy
Gregg, Eugenia, Andi, Cynthia, lee, Gian, Matt, Doyle
jg a large problem that i see is people using images to stylize text and although alt-text is available, even when it is rendered, it is not styled.
jg if i have low vision and am trying to access a page, i might not be able to increase the size of the alt-text.
jg primarily, concerns from browser implementation. alt-text for client-side image maps is not rendered.
jg conditional content of alt-text is not well supported yet. hard to call it a text-equivalent at this point.
jg rebuttal was that already part of 1.3. it fits there, but this is such a pervasive problem that we should bring it into its own checkpoint.
js could it be success criterion under 1.3?
lgr agree
wac under level 3 - "no images present text in raster"
jg but that's not the interpretation of 1.3
lgr running up against the backwards compatibility bugaboo
jg stylized alt-text not supported, thus not accessible (if use images and alt-text).
jw concern that the issue is a very html-specific issue. need to ensure it is generalized.
jw what is the general principle?
jw is there one that it fits best under or several? we should retain technology-neutrality.
jg not clear that 1.3 may not cover the situation.
js the principle is customizability.
js sounds like a success criterion rather than a checkpoint.
jg "ensure that font size and styling of text is easy to change."
jw my speculation, not a concrete proposal, might be worthwhile to draft a principle (perhaps guideline 5) that would try to address the issue to deliver the most customizable content that you can.
jw mentions proxies, server-side, etc.
wac really talking about a stop gap, right? this is a problem today. uaag says should be a uaag thing in the future?
wac not as much css support as needed
jg lots of css support.
<mvittoria> really, I try with CSS, but the browsers not run well
jg doesn't seem to be moving in that direction very quickly.
jw in my message yesterday, "don't rely on raster-based formats when the uaag has the capability of vector images." i.e. use the most semantic available for the format.
js is that why heading for 5 - for tech robustness and flexibility?
jw agree w/wac that a consequence of applying 1.3 successfully, although not clear.
jg who is the audience of guidelines? other w3c working groups?
refer to"Requirements for WCAG 2.0particularly the section onAudienceandnon-technology dependent
jg i hear two things: we want future looking also hearing compatible with older technologies.
jw in the guidelines, checkpoint and success criteria there is nothing that relates to any specific technology (old or new). in the techniques, those issues are covered.
jw keeping everything that were in "until user agents" clauses out of the guideliens.
jw as a consequence of that, when we have types of issues that relate to particular technologies we abstract out the general principles since those should apply to future technologies.
jg success criteria can change over time?
jw no they can't change, but the available techniques can.
jw one of the checkpoints (currently 5.2) allows the author to choose which techs they will rely on to implement the content.
jg if i write a web page at time 1 and conform, then techniques changes i no longer comply.
jw no. you set a baseline. you've implemented the guidelines according the techniques that are applicable for your techniques.
jw whether you've succeeded or not is based on the success criteria. when newer technology comes out, may adopt and conform to higher level success criteria.
jw conformance is based on success criteria.
jg you have success criteria, not dependent on techniques. i can ignore techniques.
js the success criteria are testable. how you achieve them is up to you.
js you can follow the techniques if they are useful, but if you have a better one go for it.
jg i am suggesting that a success criteria: resize and rescale fonts based on user preferences.
jw 2 candidates: do something that relates to 1.3 the other is a possible checkpoint under 5 (has other purposes as well as this).
<PatBertin> just as on section508.gov website
wac author should not cause restyling, the browser restyles. have trouble with jg's wording.
js use technology that can be restyled.
jw success crierion could say "possible to do from user perspective." have trouble with that because there could be technologies/ua where that takes place on the server, you have a thin-client.
jw as long as they can express preferences to server, ...
jg (earlier said) restyling not only be visual, also auditory. e.g. a voice app
jg my criteria is only to demonstrate...it doesn't have to be on the browser. if it's on a server, that's another demo that you've satisfied it.
jw does anyone want to work on a proposal?
jw or does anyone have serious reservations?
lgr if you can extract the text representation, isn't the presentation strictly up to the UA?
lgr trying to get back to teh question about what needs to be in the content? responsibility of ua versus responsibility of author.
jg author chooses particular technologies, i'm saying that there should be ar equirement that no matter what they choose, the success criteria is that the user has the ability to adjust.
lgr this starts tying the decision to the UA that will be used.
wac can see jw and js point that this becomes part of choosing a technology that can do that. 1.3 compliments by saying, "here's how you should use it."
-Jon_Gunderson
<PatBertin> i also agree with the point that the author has to leave the chance to adjust. custumabiliy is essntial in order to have the most accessible information
pk interested in working on 1.3 and 5.2, not sure i understand the 3rd issue.
<mvittoria> the user have to adjust
jw sending a raster-based image to someone who wants to adjust font size is not a good match between needs and capabilities of UA.
action pk: draft something for 1.3 and 5.2
<PatBertin> actually, i think the user shall have the chance to adjust meanwhile the author shall provide the most accessible content at the first glace leaving the user the right to custumize it it the content as given doesnt fit his/her needs
js i'm more interested in 1.3/5.2 thing.
action pk, js, jw: draft proposal for 1.3 and 5.2-related to jon g's issue on stylized text. 31 october meeting we'll discuss
jw usage scenarios to discover gaps of materials that we have and how different groups will use.
jw requirements on guidelines/checkpoints (refer to req for 2.0), however also reqs on how they will be used...thus need to design for those.
wac outlines issues and thoughts. based on The Inmates are Running the Asylum by alan cooper. particularly that we are likely to have 3 primary personas for each of the three primary pieces of deliverable:
wac the goal is that the other personas in the cast will benefit from the tools, but that we will be successful if we design for the primary personas (ala Alan Cooper).
lgr do we expect uaag devs?
wac yes, hope if we focus on atag dev, the uaag dev will also benefit.
jw agree. atag and uaag depend on wcag.
lgr uaag implementor has different relationship. uaag has to figure out how to consume.
pk agree
lgr ua implementor doesn't have to worry if alt-text on idff images, but worry about how to present.
jw uaag deal with that.
wac looking at wcag to see what is required (what attribute on which element) go back to uaag to see how to present.
lgr i can envision "i really prefer present this way..."
action wac:come up w/set of nterview questions that people can use when talking with people to collect information for the personas.
js volunteers to talk with web devs at UT austin
lgr volunteers to talk with some ua devs
jw volunteers circulate to local people in melbourne who attend accessibility conferences
wac want to avoid creating personas based on assumptions. want to do some intervies.
pk volunteers to circulate among web devs around her
jw coordinate w/EO. some of the gaps could fall under their activity or might fall into areas that both groups have an interest.
wac tries to get interview questions by 7 october, if not 24 october.
wac be gone for next 2 weeks at conferences
jw one doc that doesn't exist that could be part of an eo, is a "here's the range of 10 or 12 diff authoring tools, here's how to implement using those tools"
jw deals w/bob's comment about what content devs w/less tech-specific knowledge need to know.
js definitely going to csun
pk likely to make csun
lgr likely to make both
aa prefer csun, but boston might be more possible
bf possibly boston
bc either or both
wac also possible that have a small contingency go to tech plenary gather info, take it to regular mtg at csun
wac will send more info about the possibilities to the mailing list.
lgr interested in the responses we've gotten.
wac issues/comments will be added t issues list so we can track
jw as we move into the process, comments have to be dealt with formally.
jw if we start the good practices now, less trouble later on.
wac close to an issue tracking tool. a couple more issues to work out.
lgr looking at bob regan's comments. "level 2 conformance seems to imply that 3rd party .. is required."
js i don't that's right. it says, "has been reviewed." not by whom.
lgr could be misleading if he interprets as 3rd party.
js but that's not the intent?
jw no. but it is open to that. if a 3rd party wants to make a conformance claim about someone's content, they are entitled to do it but no requirement that they should.
js maybe just add something. it's a stock phrase "content has been reviewed..." perhaps "by an internal or external group"
jw suggest no to every sentence. right now, in appendix. but there is advice on user testing as part of review process.
jw at least there is a piece where we discuss what review means. perhaps improve the visibility of it.
js thinking about the language of the phrase that is used repeatedly.
js "by the author or others."
wac the clearer we are, the better. the less places needed to get the clarification, the better.
jw instead of lengthening the sentence, perhaps link to review section at each one.
lgr that could work.
action js: propose text that clarifies that "content has been reviewed..." does not impley 3rd party.
js people don't always look at other information. thus, mitigate if put it in line.
js - try for end of next week to satisfy action item.
jw 3 options on the table: 1. do nothing 2. change phrase 3. create a link
wac or perhaps some combination of them.
lgr perhaps put something into the conformance section?
lgr suggest that we wait until see john's proposal.
jw that's fine.
$Date: 2002/10/03 22:32:44 $ Wendy Chisholm