On the phone: Wendy, Lee_Roberts, Matt_Mirabella, MattSEA, Lisa_Seeman, Gregg_and_Ben, Jason_White, Andi_Snow-Weaver, Bengt_Farre, Avi_Arditti, Loretta_Guarino_Reid, John_Slatin
On IRC: Ben, bengt, MattSEA, PatBertin, Zakim, wendy, MattMirab
Patrizia Bertini, Roberto Scano, Maurizio Vittoria, Gian Sampson Wild
lgr metadata is higher on other checkpoints.
wac describes dc:education audience element. suggest at level 1.
lgr whatever, make it consistent.
gv metadata increases accessibility or ease of finding accessible content.
wac both
gv how?
wac data aggregation. web a collection of components. how you aggregate is based on preferences, application, etc.
lgr must we aggregate?
wac it could be a technique.
jw for identifying audience, does not increase accessibility it increases discoverability.
ls the way it is written, we are trying to educate. tried to move away from saying "this is accessible, this is not." instead, think about the issues.
ls the first thing you have to do is to decide who are the people with disabilities in your intended audience.
ls thus, a level 1. if you have not done that, everything else will fall by the wayside.
gv we are not going to be able to have any requirement that in order to do it you have to have knowledge of disability.
gv some of your comments assume that people understand disability.
gv we can not mandate that - people are required to learn about groups of people and then document what they can or can not do.
gv level 1 is "every single person on every single site needs to do this."
gv i wasn't sure when it was suggested that there be something at level 1 what is needed. does it mean we need metadata?
gv does it mean people need to create linkages between all of their documents?
gv if so, then we have to be very specific.
gv if we have a list, you must do all of these items, that is specific, but then judge if it can be done on every site.
gv metadata can be used to help people find accessible content as well as make things more accessible.
gv recommendations for metadata?
gv provisional that metadata be included (pending a standard way to use metadata and how to use) .
jw even tho we are discussing metadata issues, let's take a step back and discuss the proposal.
wac agree. could we discuss the use of questions for level 2? thought it was an interesting technique.
ls i think metadata can change the face of accessibility. i put a draft vocabulary on my site. i proposed RDF techniques.
ls want people to have idea of what fun we could be having.
ls there is a lot we can do in relation to 4.1.
ls i'd be happy to brainstorm about techniques w/anyone.
jw reactions to proposal in general?
jw is it desirable? how move forward?
jw review individual items in the list?
jw most important for us to discuss today is the structure and fine-tuning.
gv general comments: if you look at the items they fit into some categries. some require judgements about how someone w/cog dis would use something.
gv i don't think any of those will be useful since i don't think web devs can answer those questions.
gv another category: we have to ask if they can be done on every site?
gv e.g. "one idea per paragraph"
gv previously we didn't outlaw tables, although they caused problems for people who are blind, because it was too restrictive.
gv thus a category of things that are overly restrictive.
gv would be fine at level 3 - where you really want to tune your site.
aa that's an interesting point. when attempt to write in plain language, sentence structure is typically where you start.
aa if you did that, you would reallyhave the stamp of approval. thus, you would be at highest standard (if they were level 3).
ls i think the strength is the flexibility. we need a different approach on this than the other checkpoints.
ls we can't tell people how to write. so we've worded this in such a way that it doesn't tell them what to do, but gives them reasons for exceptions.
ls it then has wide applicability. instead, "when a longer sentence, make sure a valid reason>"
ls the requirement is that you discuss it. that *is* applicable on every page.
ls it brings ideals of plain language to every page.
gv the 3rd thing i was going to mention, we can ask people to do things but not reasonable (impossible?) for us to take each page and markup .... we shoot for AAA, sites that aren't going to or can't ...markup every item you can't do?
gv at level 1 there are 5 reqs, as long as i explain why i didn't do it i can be ok.
ls have editorial discussions. don't even have to markup.
aa not *every* time, "general speaking."
gv if I have a site and i write up why i didn't make it accessible, i can claim that it is accessible?
ls you have to identify when you are not conforming. in editorial discussions and have a valid reason.
ls in techniques, outline that type of process.
ls thought about giving a list of valid reason as a technique rather than checkpoint.
ls don't want to become overly formalized. you have to do that yourself. in techniques give guidance about how to decide which groups are likely to be in your audience.
ls for most people, it will be every group.
ls thus, not expecting people to understand cognitive disabilities. only if writing for specific audience.
ls building flexibility and testability w/out making overly cumbersome. think we'll have to give ourselves a bit of a break.
ls this checkpoint needs to be handled differently otherwise it becomes too watered down.
jw at least at levels 1 and 2, we are introducing review requirements with certain constraints.
jw we've often discussed matching audience and content w/out arbitrary exclusions.
jw "the content has been reviewed, taking into account these features and is believed to take into account as many as possible..."
jw then specify what can be done to prevent arbitrary exclusions, we could allow people to make an
jw honest assessment and fair and accurate in carrying out the review.
jw in level 3, controlled language (if we define) is appropriate.
jw especially at minimum, basically a review requirement but need to specify what it is.
jw if the requirement is written to prevent excluding people with cog disabilities, i think it is consistent with other parts of the guidelines.
jw the list given should be under the review requirement.
jw an attempt to bring together latest proposal and related issues.
gv asks for people to speak who has not yet spoken.
lr if we give people the option of self-determination on level, does that detract from level 1?
gv not if the alternative is to leave it empty.
gv there is so much that we can think of to do, but we can't find something objective.
gv i understand what you are saying.
gv if it's not possible to always require, can we structure it so that people have to look at it.
gv i thought statements of do this to question of "have you done this" is interested.
gv it's not the form of our success criteria. is there a way to make them consider these things, but can we do them in a way...
gv asking questions rather than listing them as declarations is an interesting way to cause people to stop and think about them.
gv i thought the question asked was, "does allowing people to self-judge weaken level 1?"
gv yes, it is weaker, it is not objective, however we face a problem of not finding things in this category that we could put in level 1 that are objective, applicable to all sites,t ec.
gv thus either an empty level 1 or level 1 that has something like what we've been discussing (a declaration).
gv aa and ls proposed somethign different, "you can skip if you document why you skip."
gv everyone can do that but the act of writing something down might be embarrassing enough that it woudl cause them to do more.
lr where would that developer put that summary or discussion of why they didn't do a, b, d but did do c.
gv yes, my concern. perhaps in internet policy page that links to accessibility policy and describes why they did or didn't do things.
ls if we like this approach then the next stage is to develop the supporting documentation.
ls these materials would specify what constitutes valid reasons. e.g. a quote.
ls perhaps a priviso, if we can not create an exhaustive list, for other reasons that might be as strong.
ls English techniques similar to HTML.
js devil's advocate: does it count as a legitate exclusion if the person constructing the site that they honestly have done the best they can? i have a lot of students who make good faith efforts whose stuff is pretty awful.
aa we don't draw distinction between good graphic or bad, so that ties into what you are saying.
ls lack of ability is not an excuse. before WYSIWYG, people couldn't alter html w/confidence to make it accessible.
ls I can not, without tools, write something will correct spelling. I have to use tools.
jw i think we primarily have a review requirement. perhaps reformulate the points as questions.
jw include the idea that we should give guidance about answering no to some of the questions.
jw somewhat constrain the review process.
jw we need a more precise statement of what the review requirements are.
jw i put forward some idea yesterday, but did not work on a formulation of review requireemnts, particular piece related to audience.
jw also, need to go through all of the items that were suggetsed.
jw first, create satisfactory review reqruirement then fine-tune the items underneath it.
jw formulating them as questions only implicity suggests the desired answers.
jw thus fail to specify desirable answers.
jw unless, we say, "all questions answered affirmitively except where exclusions..."
jw we need to make our expectations explicit.
lgr i like the review approach. for people who are motivated, these questions/suggestions are valuable.
lgr will we ever be able to ensure people will do the right thing? if we can at least guide them.
gv yes, guide and encourage.
gv could a group take these comments from today, and do something where it does not require capabilities of people with disabilities.
gv could say, "people who can't read" but not "learning disability, etc."
gv make it plain language. :)
ls why not do that in the supporting document?
gv it would require that people need to be educated to use the guidelines.
ls the informative sections? most people need to use techniqes anyway. otherwise, fall by the wayside.
ls what is appropriate for one type of content not appropriate for another.
ls we do want people to udnerstand that some people can't see. thus, we do expect people to understand disability.
ls we can minimize the learning by providing techniques.
ls clear instructions about what words are acceptable or not (for your audience).
aa originally, i left all references to users general. ls made the point that w/in a medical journal audience, some may have early stage alzheimer's, dyslexia, etc.
aa we were trying to keep it streamlined.
js the audience for this checkpoint is different from other checkpoints.
js the other checkpoints are addressed to people with good technical skills, using technical solutions to accessiblity challenges.
js this less technical. addressed to writers.
-Loretta_Guarino_Reid
js perhaps a level of discomfort since we're used to proposing things to the technologist.
js perhaps part of sharpening our understanding of who is our audience.
jw or if the same person, they are doing something different.
jw often same person who does all of the steps in the process.
aa i'm happy to keep tweaking. it seems that we are getting closer. it just needs to be packaged better.
ls perhaps submit to the list, "do we want to throw out requirements?" requires people to think about what disabilities and skill set of the audience.
jw another way to do that, "you must think seriously about the comprehension abilities of people coming to the material"
jw sometimes hard to determine.
jw if someone reading my thesis they must have read most of the references i have discussed.
jw my writing should then be written at the same level. but if writing a commerce site, harder to decide what the linguistic capabilities should be.
jw what do we want people to consider when thinking about audience?
jw if we do that we have a checkpoint where the review process is contrained to the extent that whoever makes an honest attempt is considering the right matters.
jw those who are not honest, we can not do anything about. i think they will either say they have satisfied it or not try to satisfy the guidelines.
jw does anyone want to comment on the list of items?
aa 13 in 1st, 25 in 2nd.
gv i suggested that we take a look. many have issues, e.g. making assumptions about the user.
gv as much as possible, shouldn't need to read techniques to decide what to do, rather "how" to do it.
gv if the list could be pruned so it doesn't say, "does it work for x group?" if you don't know the group.
aa what if instead say, "users w/in your audience.." but earlier on say "you must not exclude any particular groups..."
gv some say audience and some say intended audience.
gv since it's a web site they could be from anywhere on earth. however, "intended" users, i could say "i intend..."
gv i you say "you must intend for people with disabilities..." then i am back in the first category... i am back at "i have no idea wht they can do."
aa rather than say "do you think people will be able to do this" but "do you think people will think they can do this."
gv they have no idea bout their audience.
aa then paint yourself into a wall. what is a 3rd way?
gv that's why we are wrestling.
ls don't want things in techniques...
js is there a way to make the same points and raise the questions in web authors minds w/out putting them in the position of making declarations of what is going on at the receivers end.
js i can't know whether you do or don't understand me. i can only contorl what i say or don't say.
js if you understand it or not is not in my control.
aa to push more, you risk putting people on the defensive. thus, strike a balance. be gently prodding.
js can we make sure that those questions refer back to characteristics of the text rather than the audience.
js questions about what they've written rather than what is happening within the mind of the reader.
aa instead of "abbreviations and jargon" instead say, "as clear as can be."
js are they consistent with the usage in the field you are writing.
jw usage might be unduly complicated.
jw there are some lawyers known to do it deliberately.
aa current w/good practice.
ls "do you use aid comprehension."
ls "do you use sentence lengths that maximize comprehension"
asw still lots of judgement on the part of the author that they might not be capable of doing.
aa you are writing for an audience, you are not writing for yourself or into a vacuum.
js in writing instructions, we help students develop a better understanding of their audience.
js if the question contains info about the impact of a disability on the understnading, then, "does your text meet this criterion"
ls we started by talking about metadata. 1st thing: what are the cognitive skills required for your site.
ls or do we want to go through each requirement and try to find a way that exactly informs people what to do if they do not understand the audience.
aa rather than set a standard for htis checkpoit that is higher than others, try the more general principles of plain language nd hope people do their best.
aa start w/subsets (might work with this iq range might not work with 10 points higher).
aa instead of having people throw up their hands (I won't even try) get them to do *some*thing rather than nothing.
jw to emulate other checkpoints, "content has beenr eviewed and believes to have x characteristics" w/out reference to audience but principles of good design.
aa that sounds good to me.
ls didn't really understand.
action aa, ls take another look at 4.1 based on today's discussion.
gv i would like to see at the highest priority, things that an assistive technology (that doesn't exist today...something that could transform things) could not do.
gv we have to be careful not to say "you must write well." the idea of "did you try" or "do your best" is good.
gv from industry point of view, there are things that companies can not say b/c someone may require them to prove that. i want to be careful that we don't do something at level 1 that gets into that quagmire.
gv whatever we dont' practice in our email exchanges we shouldn't expect that do be done on web sites.
ls i completely disagree.
ls it's important that people ahve input from people with comprehension problems. (input into wcag) does it mean i am capable of writing well? no, by definition i am not.
gv so we shouldn't allow you to be on the web?
lr based on your definition, you were limiting lisa.
gv if we make rules, lisa would not be able to have a web site.
ls no, it doesn't mean i can't have a web site, it means i have to do certain things.
gv why can't you do them to the email?
js the conventions for email are different than publication on the web.
js rather than looking at email, we should look at our own practice on the web.
gv many of the suggestions we could not do with our own content.
gv it is an interesting litmus test.
aa i would like more guidance on what is an approach that is acceptable and consistent.
action wac send email to avi, lisa, and lee to get discussion started (help assimilate today's discussion). make sure that intended audience is addressed in a way that meets john, andi, and gregg's concerns.
$Date: 2002/10/24 23:22:12 $ Wendy Chisholm