Roberto Scano, Dave MacDonald, Wendy Chisholm, Ben Caldwell, Gregg Vanderheiden, Jason White, Gian Sampson Wild, Avi Arditti, Bengt Farre, Francesco Fedele, Kerstin Goldsmith, John Slatin, Loretta Guarino Reid, Andi Snow-Weaver, Cynthia Shelly
Roberto Ellero, Doyle Burnett, Lee Roberts, Michael Cooper
the 4 types of claims
1st is a negative
the others start with "if x then y"
rephrase 1st as positive
john's proposals for rewording descriptions of conformance claims
Resolved: incorporate John's suggested wordings for conformance levels, put conformance section into new draft. this section ok to go to TR.
mapping issue: there are 3 WCAG 1.0 checkpoints that map to this and they are all p3 (in 1.0)
babelfish.altavista.com doesn't find an italian translation for "unabridged"
moving things from p3 to core, there are other checkpoints with this issue. e.g., summary attribute. concern that it could become a general statement of principal (i.e., never move p3 to core)
unambiguously decode doesn't mean can understand what they mean.
just because it is something that can be done is it really practical and beneficial.
seems more of a usability issue than accessibility issue
there are places where it doesn't make sense to expand the acronym, e.g., jpg or DVD.
perhaps go to Extended w/editorial note
editorial comment summarizing the issues.
could run into problems with content management systems if make it core. many people using lotus notes and other sytems that use deprected features of w3 technologies (thus can't claim AA to WCAG 1.0).
many people don't know innerworkings of html, thus abbr element. thus difficult if put it at core.
what are the issues? perhaps move to extended w/out a note?
backwards-compatibility with 1.0 - separate issue that we don' thave time to get to today.
make sure issue in bugzilla
do we have anyone that could answer the question about the importance of this for cognitive disabilities?
acronyms are less important than other isuues about cognitive
reviewer's who can answer this question. thus if put in editorial note could flag that for them, but i would also ask a general review question for them to look over all of them for feedback
it comes down to "the purpose of the content."
resolution: in extended checkpoints. general resquest for review (when TR draft published) to people with interest in cog area.
add anything about "use common sense" "if it's likely to be misunderstood, a good habit to extend"
seems that it goes into best practice since not testable
core extended and best practice? best practice w/in each.
would not exist as checkpoint as own.
what is most important to be included in metadata for cognitive disability assistive technologie?
only editorial note at this point would say something about possible best practice about "if it's likely to be misunderstood, a good habit to extend"
Designing for users with Cognitive Disabilities
4.2 Technologies that are relied upon by the content are declared and widely available
Technologies that are relied upon by the content are declared and widely available
probably can not go in core. determining the list is subjective.
happy to leave in extended until determine what do in the long run.
implications such as wcag 1.0 p1 checkpoint that says docs readable w/out style sheets. this is only for html, but perhaps to make the list less subjective we make some specific issues for technologies. the issue w/this is that we want it to remain technology-agnostic.
however, wrt to css - if have followed other checkpoints should have provided appropriate structure.
trying to say, "have features required for optimal features, however, if don't have it is still usable."
if that what cynthia was trying to say, then there is an extra not.
suggested rewording: all technologies that are used to render are listed and all can be turned off.
if the technologies are required to suppor the content are available or turned off there is an alternate version of the content that uses less wizbang stuff, roughly equivalent (e.g., embed jpg in object for people don't have flash)
proposed editorial note: lots of issues w/this one. summary of implications. replaces current success criterion. unless get better wording from jason.
trying to get at with this checkpoint: you know what technologies you designed your site for (x, y, z) after evaluating features (including accessibility).
if some of those are not html, have a fallback that is known to be accessible.
may not be completely different version. style sheets are a good example.
if the user doesn't have a browser that supports CSS, the user can still read the content.
i.e., it renders on your display and in the right order.
about defining a baseline
if not completely mainstream, fallback to something that is mainstream. might be separate uri, separate query to database, image instead embed inside object, text that doesn't look the way you want, links instead of a menu, etc.
say deterimned rather than declared
action: john and cynthia work on wording of success criterion of checkpoint 4.2
action: wac write editorial note that summarizes implications of this checkpoint being in extended rather than core
technologies are required for content are declared and widely available" - then someone could say "jaws is required to access my content"
is the problem w/this checkpoint b/c this is the whole point of the guidelines? that content should transform gracefully? that was problem with 1.0 is that we said, transform gracefully as a checkpoint but was main theme of the whole doc"
wanted "step by step" process rather than other people determining what has happened. this is not a development practice document.
all this says is list the technologies. it doesn't talk about making transform gracefully.
it's only that you declare what is required to access it.
if we have done a good job designing checkpoints, then the content should transform gracefully.
technologies are required in order for content to be accessible are available on the site or a link to them is provided"
that means have to have screen readers on the site. what about for-profit technologies.
if an accessible version of a plug-in is needed to meet the guidelines them it is provided on site or link provided.
e.g., pdf viewers are accessible, but that's not the one that most people have.
technologies required in order to meet these guidelines are declared and a method for locating them is provided on the page
that success criterion)
proposed text for checkpoint: Technologies that are relied upon for accessibility by the content are declared and locatable
john and cynthia will consider this wording while working on their action item.
technologies don't meet guidelines, the content does.
this also about development process.
also an editorial note that this could possibly disappear.
interoperates w/accessibility agents that support accessibility
device indie can not be required since it does not mean accessibility and requires things not needed for accessibility.
cut this one.
resolved: editorial note that we want to cut it and get feedback on it.
$Date: 2003/06/16 19:28:25 $ Wendy Chisholm