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.

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.

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.