- From: Wendy Chisholm <wendy@w3.org>
- Date: Thu, 14 Jul 2005 18:06:20 -0400
- To: w3c-wai-gl@w3.org
Available at: <http://www.w3.org/2005/07/14-wai-wcag-minutes.html>
[1]W3C
[1] http://www.w3.org/
WCAG WG weekly telecon
14 Jul 2005
[2]Agenda
[2] http://lists.w3.org/Archives/Public/w3c-wai-gl/2005JulSep/0044.html
See also: [3]IRC log
[3] http://www.w3.org/2005/07/14-wai-wcag-irc
Attendees
Present
Michael_Cooper, Ben Caldwell, Christophe_Strobbe, Wendy
Chisholm, Yvette_Hoitink, Sebastiano Nutarelli, Bengt_Farre,
Gregg_Vanderheiden, Becky_Gibson, Luca_Mascaro, Tim_Boland,
Roberto Ellero
Regrets
Roberto_Castaldo, Alex_Li, Roberto_Scano_(until_15_August)
Chair
Gregg
Scribe
wendy
Contents
* [4]Topics
1. [5]Techniques Task Force update.
2. [6]guideline 3.2 techniques harvest
3. [7]Guideline 4.2 techniques harvest
* [8]Summary of Action Items
_________________________________________________________________
John called in to thank us for the song and say "hello" :)
Techniques Task Force update.
mc: will be finishing review of existing tests (about 100 of them) as
well as pending (about 25). will be sending proposals to the list and
gathering feedback using surveys, similar to guidelines.
... script tests - not sure what they will look like. feel that need
techniques before can write tests.
... from the harvesting, focusing on developing script techniques.
looking at how to coordinate with experts.
mc: some editorial and structural changes to html techniques to make.
easiest way is to make the changes to an internal draft (rather than
writing proposals for each change).
... not likely substantial changes, except addition of testable
statements for each technique.
resolution: michael will make some editorial and structural changes to
html techniques and publish an internal draft for review.
guideline 3.2 techniques harvest
<Michael> Mapping document:
[9]http://www.w3.org/WAI/GL/2005/06/30-sc-techniques-mapping.html
[9] http://www.w3.org/WAI/GL/2005/06/30-sc-techniques-mapping.html
L1SC1 - Any change of context is implemented in a manner that can be
programmatically determined.
CSS inherit
w/inherit property children will accept computed value of parent
change of context?
at least for rendering purposes, might facilitate similar look and
feel across elements.
need an alternative to "target" since not allowed in strict html. rel
is external then programmatically open new window.
script techniques
issues with SC? what does it mean to programmatically determine
opening a window in script?
using "a" is one way to satisfy this. have technique for using? [or
just refer to html spec]
L2 SC1 Components that are repeated on multiple delivery units within a set
of delivery units occur in the same order each time they are repeated.
currently - CSS about indenting text. not properly mapped.
server-side includes
templates
cms to help
general tech about introducing subitems to clarify allowed
L2 SC2 When any component receives focus, it does not cause a change of
context.
in html, techniques that discuss onfocus event handler and what not to
do when activated
on forms submit, have to use submit so that doesn't rely on focus to
cause submission
does this address issue w/tabbing to menu itme and menu item opens
automatically (on tab into)?
change of context - A change of user agent, viewport, user interface
controls, or focus; or complete change of content.
L2 SC3 Changing the setting of any input field does not automatically cause
a change of context .
becky's submitted scripting technique using onchange on select (in an
accessible way)
somewhat controversial (but will log and explore)
question about: technique to address issue that automatically advances
you to next field after enter x # of characters? when hit back to fix
an entry, now in different field.
L2SC4 Components that have the same functionality in multiple delivery units
within a set of delivery units are labeled consistently.
this is more about generating the page rather than fixing later.
perhaps general technique "just do it..."
L3SC1 Graphical components that appear on multiple pages, including
graphical links, are associated with the same text equivalents wherever they
appear.
test - if a graphic is associated with different uris on different
pages, flag them and determine if differences make sense. if not, make
consistent.
L3SC2 Changes of context are initiated only by user action.
no automatic refreshes, at all.
navigating around page, shouldn't cause change of context (e.g.,
pop-ups). however, this meant to mean "only by user request."
minor issue with wording of SC. "user action" a bit too vague
<scribe> new bug for this issue -
[10]http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1535
[10] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1535
"on leaving a data field"
html-specific?
resolution: adopt L3SC2 Changes of context are initiated only by user
request.
use links to cause page to refresh
(or section of a page)
instead of automatically causing refresh
changes of user agent:
discussion about issue.
other parts of the defn of "change of context" - have we addressed
"change in user interface control?"
mentioned earlier (becky's proposal)
Guideline 4.2 techniques harvest
L1SC1 If content does not meet all level 1 success criteria, then an
alternate form is provided that does meet all level 1 success criteria.
discussion about concerns with this SC
issues raised - 1. does this apply to content outside the baseline?
also applied to content inside the baseline?
perhaps say something along the lines of, "If content outside the
baseline does not meet..."
however, tech may not be capable
If content can not meet...
"can not" would have to apply to technology not the author (or
cost/effort)
if scripting in baseline, still things can do that don't meet the gl
so still need to provide an alternative form.
if you can make it accessible you must...
[11]http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1536
[11] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1536
noframes, noscript
fallback mechanism for applets (if applet not in baseline) need
alternative mechanism for funcationlity
content negotiation
set of general techniques links to alternatives
(concern about these and cyberghetto)
user settings, store preferences
style switcher
L1 SC2 # Content using baseline technologies or non-baseline technologies,
must meet the following criteria: [V]
1. Content that violates international health and safety standards
for general flash or red flash is marked in a way that the user
can avoid its appearance Editorial Note: @@ update to match 2.3
text when it is complete
2. If the user can enter the content using the keyboard, then the
user can exit the content using the keyboard.
several techs already mapped to
concern about mappings
map to SC1 instead?
gen tech about keyboard handling
gen tech about not trapping keyboard
javascript keyboard event handlers. how to return t/f if handle or if
OS handles.
"hit x to return to previous page"
covered by "must be able to use w/keyboard"
this abut getting trapped in a plug-in
can never use contentEditable?
should document work-arounds/games/kludges related to
L1SC3 The role, state, and value can be programmatically determined for
every user interface component of the web content that accepts input from
the user or changes dynamically in response to user input or external
events.
there are techniques but can't validate right now and don't have spec
*yet*
however, if use elements semantically correctly would satisfy to best
of ability. also, in some techs (flash) dont' you have to do for info
to get passed through?
concern that people creating UI elements with a and div and is that
not using the elements semantically correctly
issue - is it possible to meet the strict interpretation of this in
html? if not, what is the intent? can we meet the intent with other
wording?
[12]http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1537
[12] http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1537
L1SC4 The label of each user interface control that accepts input from the
user can be programmatically determined and is explicitly associated with
the control.
label element for most controls, alt for image input, value for most
buttons, text for button element
L1SC5 The states and values of content that can be changed via the user
interface can also be changed programmatically.
how different from 3?
determined vs changed
DHTML roadmap techniques
java and flash techniques
primary concern now about programmatic objects. mapping to UAAG 1.0
that all things are covered.
eventually xhtml. perhaps confusing now for html devs, but need to
document in guide asap
L1 SC6 Changes to content, structure, selection, focus, attributes, values,
state, and relationships within the content can be programmatically
determined.
document.write
w/java if using classes that include accessibility then get for free,
but if not then need to ensure that do these things
point to external documentation that explains/shows
redundant with using accessibility conventions? no - if use
accessibilty features, get for free. if not, need to do the things in
L1 SC6
L2SC1 Accessibility conventions of the markup or programming language (API's
or specific markup) are used.
"Creating Invisible labels for form elements" is mapped here. should
remap to L1SC4
people interpret this to mean that they have to use all accessbiility
features (e.g., accesskey, tabindex) that not necessarily the case.
document the user agent issue where accessibility features are not
supported or supported inconsistently
L3 SC1 Content implemented using technologies outside of baseline follows
all WCAG requirements supported by the technology.
all uses of javascript on a site (if js not in baseline) are
accessible and also work with out.
tech is - follow techs for that tech
Summary of Action Items
[End of minutes]
_________________________________________________________________
Minutes formatted by David Booth's [13]scribe.perl version 1.126
([14]CVS log)
$Date: 2005/07/14 22:05:03 $
[13] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[14] http://dev.w3.org/cvsweb/2002/scribe/
_________________________________________________________________
Received on Thursday, 14 July 2005 22:06:39 UTC