[minutes] 14 July 2005 WCAG WG weekly telecon

Available at: <http://www.w3.org/2005/07/14-wai-wcag-minutes.html>


       [1] http://www.w3.org/

                             WCAG WG weekly telecon

14 Jul 2005


       [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


           Michael_Cooper, Ben Caldwell, Christophe_Strobbe, Wendy
           Chisholm, Yvette_Hoitink, Sebastiano Nutarelli, Bengt_Farre,
           Gregg_Vanderheiden, Becky_Gibson, Luca_Mascaro, Tim_Boland,
           Roberto Ellero

           Roberto_Castaldo, Alex_Li, Roberto_Scano_(until_15_August)




      * [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

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


    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

    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

    test - if a graphic is associated with different uris on different
    pages, flag them and determine if differences make sense. if not, make

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

    "on leaving a data field"


    resolution: adopt L3SC2 Changes of context are initiated only by user

    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

    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

    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

    there are techniques but can't validate right now and don't have spec

    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


      [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


    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