ACTION-709 - Find the email thread about 1112 and send to list

This action is related to the long call in Jan 20, 2012. 1.11.2 was on
the list for a yes/no vote. it had a note of "email thread". here are
the threads related to this SC. Now we need to decide is it ok
Simon original proposal
http://lists.w3.org/Archives/Public/w3c-wai-ua/2011JanMar/0040.html
Greg response http://lists.w3.org/Archives/Public/w3c-wai-ua/2011JanMar/0046.html

discussion in meeting
http://lists.w3.org/Archives/Public/w3c-wai-ua/2011JanMar/0050.html
Writing: review and approve 1.11.2 - Extended Link

    <jeanne2>
    [34]http://lists.w3.org/Archives/Public/w3c-wai-ua/2011JanMar/0040.h
    tml

      [34]
http://lists.w3.org/Archives/Public/w3c-wai-ua/2011JanMar/0040.html

    Greg in email asked if it was about making info available directly
    to the user, or to assistive technology.

    Simon says he assumed it was about presenting it directly to the
    user.

    What would example implementation be like?

    Simon: in Wiki system a small icon identifies links to offsite
    resources.

    Simon sees a browser having a preference setting to "turn on
    extended link information" which displays all of these pieces of
    information next to the link.

    Simon: browser can tell by MIME type whether it would download, run
    automatically, prompt for handling, spawn external renderer, etc.

    Wouldn't the browser need to query the server to get MIME type?

    In some cases the browser can guess by file extension, but I don't
    think we want it to query the server for each link.

    In email suggested changing the SC wording to incorporate
    "recognized".

    Greg: what did you mean by hover?

    Simon: In CSS you can change link color based on hover.

    Jeanne: Need to be aware of giving users so much information that we
    impede their ability to navigate the page.

    To make it clearly about presenting to the user, could change "The
    following information is provided for each link (Level A)" to "The
    user can have the following information about a link presented
    (Level A)" or some such.

    Jan: Information presented on hover needs to also be available to AT
    and to keyboard users.

    <Jan> Jan: Also wonders whether all this link info is accessibility
    or usability

    In response to Jan's question, I think visited/unvisited is
    accessibility because it greatly reduces short-term memory load.

    I have trouble imagining any browser not showing link element
    content.

    Jan suggests information related MIME type, size, etc. can be done
    at link activation time, rather than displaying it on the page.

    Simon notes it's much more efficient for some users if the
    information is presented with the link rather than elsewhere (e.g.
    in a status bar).

    Similar question about whether it's OK to make the info available on
    request (e.g. on a link's shortcut menu) vs. showing the information
    for all links on the page IN the page.

    Jan notes that information appearing somewhere other than where
    you're working is a general accessibility problem.

    Simon adds tab order and access key as important pieces of
    information.

    Do people feel the things Simon proposed as Level A are all
    accessibility, not just usability? Element contents, title,
    visited/unvisited, hover text (or hover content), and whether it's
    currently selected?

    The ability to customize highlight used for selected, visited and
    unvisited links are all covered by SC 1.3.1 Highlighted Items and
    1.3.3 Highlighted Input Controls.

    So we may not need to repeat that here, but could list it in the
    Related Resources.

    Jan is OK with merely cross-referencing those here.

    <Jan> Jan: hmmm that wasn't me

    So if visited and selected are covered elsewhere, that leaves link
    content, link title, and hover content as still needing to be
    somewhere.

    Title could be considered alternative content, which is also
    addressed by another SC?

    <Jan> JR: Idea: Proximity of Status Information: The user can
    specify that status information for elements always be displayed in
    proximity to the element. (e.g. rather than in status bar etc.)

    Jan doesn't think the HTML title attribute would fall into the
    category of "alternative content" because it's not meant to REPLACE
    the primary content.

    Does that mean we need some SC to require access to title
    attributes? Or is that implied by the fact that if they show it to a
    mouse user they have to show it to keyboard users as well?

    If a browser chooses to not expose title attribute to anyone, mouse
    or keyboard users, is that acceptable?

    Simon says if it's OK if it's not available to anyone.

    One argument that could be made for presenting title being an
    accessibility issue is that if a person can't see a graphical link,
    the title might give them more information to help them understand
    it's purpose, above and beyond the alt attribute.

    So should we remove link title from 1.11.1?

    Discussion of the difference between things that we feel the browser
    needs to do to be accessible (e.g. ability to turn off images,
    providing keyboard shortcuts) , and things it needs to do for some
    users if it does equivalent for others (e.g. keyboard access to all
    features you ca do with mouse).

    <KimPatch> stepping away for a minute

    If we say that browsers don't have to display title attributes, but
    if they do they have to make it available via the keyboard, that's
    handled by another guideline so we wouldn't need to mention it here,
    right?

    <KimPatch> back

    Jan suggests creating something about the user option to have
    information displayed in proximity to the thing it is associated
    with, rather than elsewhere as in a status bar. We do something
    similar in 2.1.6 (former 4.1.6) Present Direct Commands in Rendered
    Content: The user can have any recognized direct commands (e.g.
    accesskey) in rendered content be presented with their associated...

    scribe: elements (e.g. "[Ctrl+t]" displayed after a link whose
    accesskey value is "t", or an audio browser reading the value or
    label of a form control followed by "accesskey control plus t").
    (Level A)

    The intent for that is Intent of Success Criterion 2.1.6 (former
    4.1.6): Make it easy to for users to discover or be reminded of
    keyboard shortcuts and similar commands without leaving the context
    in which they're working. Easy keyboard access is especially
    important for people who cannot easily use a mouse.

    <Jan> ACTION: Jan to Work on SC wording related to "Proximity of
    Status Information: The user can specify that status information for
    elements always be displayed in proximity to the element. (e.g.
    rather than in status bar etc.)" perhaps making use of wording
    similar to Intent of Success Criterion 2.1.6 (former 4.1.6):
    [recorded in
    [35]http://www.w3.org/2011/02/03-ua-minutes.html#action11]

-- 
Jim Allan, Accessibility Coordinator & Webmaster
Texas School for the Blind and Visually Impaired
1100 W. 45th St., Austin, Texas 78756
voice 512.206.9315    fax: 512.206.9264  http://www.tsbvi.edu/
"We shape our tools and thereafter our tools shape us." McLuhan, 1964

Received on Thursday, 26 January 2012 23:29:46 UTC