W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > July to September 2010

Minutes of UAWG Writers Meeting 3 August 2010

From: Jeanne Spellman <jeanne@w3.org>
Date: Tue, 03 Aug 2010 18:17:22 -0400
Message-ID: <4C589572.5060809@w3.org>
To: UAWG <w3c-wai-ua@w3.org>
Minutes:
http://www.w3.org/2010/08/03-ua-minutes.html

IRC Log
http://www.w3.org/2010/08/03-ua-irc

Text of minutes:

    [1]W3C

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

                                - DRAFT -

    User Agent Accessibility Guidelines Working Group Teleconference

03 Aug 2010

    See also: [2]IRC log

       [2] http://www.w3.org/2010/08/03-ua-irc

Attendees

    Present
           Jim, Greg, Jeanne, Kim, Kelly

    Regrets
    Chair
           SV_MEETING_CHAIR

    Scribe
           greg

Contents

      * [3]Topics
          1. [4]Principle 2
          2. [5]2.1.3 Accessible Alternative
          3. [6]2.1.1
          4. [7]2.1.2
          5. [8]Accessibility API reference
          6. [9]2.1.5
          7. [10]2.1.6 Properties
          8. [11]2.1.4
          9. [12]2.1.7 timely communication
         10. [13]4.1.12 Specify preferred keystrokes:
         11. [14]3.13.1 & 2
         12. [15]3.11
      * [16]Summary of Action Items
      _________________________________________________________

    <trackbot> Date: 03 August 2010

    <kford> Jeanne, can you paste a link to the doc again?

    <jeanne>
    [17]http://www.w3.org/WAI/UA/2010/ED-UAAG20-20100802/MasterUAAG20100
    802.html

      [17] 
http://www.w3.org/WAI/UA/2010/ED-UAAG20-20100802/MasterUAAG20100802.html

Principle 2

    <jeanne> [writing assignments]

    <AllanJ> 2.1.3 reference
    [18]http://lists.w3.org/Archives/Public/w3c-wai-ua/2008OctDec/0050.h
    tml

      [18] 
http://lists.w3.org/Archives/Public/w3c-wai-ua/2008OctDec/0050.html

    <jeanne> jeanne and Kim were discussing the need for a stable point
    of regard, for example, when increasing text size in a long
    document, the point of regard should be saved.

2.1.3 Accessible Alternative

    Existing wording: 2.1.3 Accessible Alternative: If a feature is not
    supported by the accessibility architecture(s), provide an
    equivalent feature that does support the accessibility
    architecture(s). Document the equivalent feature in the conformance
    claim. (Level A)

    <scribe> New proposed rewording, intent and example:

    1. If an item of the user agent user interface cannot be exposed
    through the platform accessibility architecture, then provide an
    ("separate but equal") equivalent alternative that is exposed
    through the platform accessibility architecture.

    a. Users need to be able to carry out all tasks provided by the user
    agent. The purpose of this S C is to ensure that when circumstances
    do not allow direct accessibility to some items in the user agent,
    there is an accessible option that will let them complete their
    task.

    b. For example, the user agent provides a single, complex control
    for 3-dimensional manipulation of a virtual object. This custom
    control cannot be represented in the platform accessibility
    architecture, so the user agent provides the user the option to
    achieve the same functionality through an alternate user interface,
    such as a panel with several basic controls that adjust the yar,
    spin,...

    scribe: and roll independently.

    1. If an item of the user agent user interface cannot be exposed
    through the platform accessibility architecture, then provide an
    equivalent alternative that is exposed through the platform
    accessibility architecture.

    a. Users need to be able to carry out all tasks provided by the user
    agent. The purpose of this S C is to ensure that when circumstances
    do not allow direct accessibility to some items in the user agent,
    there is an accessible option that will let them complete their
    task.

    b. For example, the user agent provides a single, complex control
    for 3-dimensional manipulation of a virtual object. This custom
    control cannot be represented in the platform accessibility
    architecture, so the user agent provides the user the option to
    achieve the same functionality through an alternate user interface,
    such as a panel with several basic controls that adjust the yar,
    spin,...

    scribe: and roll independently.

    Jan notes that they originally chose "feature" over "item" because
    all the functionality that is grouped together in the default user
    interface should also be grouped together in the alternative UI,
    rather than having to go elsewhere for one portion of it. Thinking
    of features as a whole as working or not working, rather than
    breaking it down to the level of individual controls.

    Kelly notes that in his workplace, the term "feature" is used for
    very large chunks of functionality that include controls, behaviors,
    interactions, etc.

    Kelly refers to things like "spell checking" as a feature that
    includes numerous menu items, dialog boxes, controls, hotkeys, etc.

    Jan: ATAG has high-level guidance as well, equivalent to Greg's
    point that this general idea can apply to almost anything in the
    document.

    <Jan> JR: Notes "applicability notes" construct in ATAG2.0:
    [19]http://www.w3.org/TR/2010/WD-ATAG20-20100708/#part_a

      [19] http://www.w3.org/TR/2010/WD-ATAG20-20100708/#part_a

    <Jan> JR: and
    [20]http://www.w3.org/TR/2010/WD-ATAG20-20100708/#part_b

      [20] http://www.w3.org/TR/2010/WD-ATAG20-20100708/#part_b

    This discussion started because Greg argued that 2.1.3 is just a
    single instance of the general rule that would apply to every SC in
    this document.

    That is, all *functionality* needs to be available through
    accessible user interface, but not every user interface element. For
    example, I believe that its acceptable to have an toolbar button
    that lacks keyboard access as long as the command is available
    through an accessible menu system.

    I think I sent email to the list on April 8 on this topic,
    discussing scoping and exceptions.

    I think eventually we'll be able to get rid of 2.1.3, as it will be
    redundant to some more general SC or conformance rule.

    2.1.3 Accessible Alternative: If a component of the user agent user
    interface cannot be exposed through the platform accessibility
    architecture, then provide an equivalent alternative that is exposed
    through the platform accessibility architecture.

    Intent: Users need to be able to carry out all tasks provided by the
    user agent. The purpose of this S C is to ensure that when
    circumstances do not allow direct accessibility to some items in the
    user agent, there is an accessible option that will let them
    complete their task.

    Example: The user agent provides a single, complex control for
    3-dimensional manipulation of a virtual object. This custom control
    cannot be represented in the platform accessibility architecture, so
    the user agent provides the user the option to achieve the same
    functionality through an alternate user interface, such as a panel
    with several basic controls that adjust the yar, spin, and roll...
    ... independently.

    Jeanne suggested "component". Jan suggests "functionality".

    <kford> Think about replacing component with functionality and
    appropriate wording.

    <jeanne> rssagent, make minutes

2.1.1

    <jeanne> Intent for 2.1.1

    <jeanne> Computers, including many smart phones, have accessibility
    features built into the operating system. Some well-known APIs for
    the Windows operating system are: MSAA, iAccessible2, [more]. Where
    ever technically possible, support the existing accessibility APIs.

    <jeanne> Examples:

    <jeanne> Browser A is developing a new user interface button bar for
    their Microsoft Windows product. The developer codes a call to the
    MSAA API for the functionality.

    <jeanne> We didn't try to put together the list of resources, but
    that will be needed.

    <jeanne> SC: 2.1.1 Platform Accessibility Architecture: Support an
    platform accessibility architecture relevant to the operating
    environment. (Level A)

    <kford> Issue: Ensure UAAG docus have fully updated references to
    the various accessibility APIs.

    <trackbot> Created ISSUE-72 - Ensure UAAG docus have fully updated
    references to the various accessibility APIs. ; please complete
    additional details at
    [21]http://www.w3.org/WAI/UA/tracker/issues/72/edit .

      [21] http://www.w3.org/WAI/UA/tracker/issues/72/edit

2.1.2

    My only suggestion would be to clarify in the Intent paragraph that
    this is about API for programmatic access (with assistive
    technology), rather than about all the "accessibility features built
    into the operating system".

    <jeanne> 2.1.2 Name, Role, State, Value, Description: 2.1.2 Name,
    Role, State, Value, Description: For all user interface components
    including the user interface, rendered content, and alternative
    content, make available the name, role, state, value, and
    description via an platform accessibility architecture. (Level A)

    <jeanne> The information that assistive technology requires is the
    Name (component name), the Role (purpose, such as alert, button,
    checkbox, etc), State (current status, such as busy, disabled,
    hidden, etc), Value (information associated with the component such
    as, the data in a text box, the position number of a slider, the
    date in a calendar widget), Description (user instructions about the
    component).

    <jeanne> For every component developed for the user agent, pass this
    information to the appropriate accessibility platform architecture
    or application program interface (API). Embedded user agents, like
    media players can pass Name, Role, State, Value and Description via
    the WAI-ARIA techniques.

    <jeanne> Example for browser (not complete)

    <jeanne> A browser is developing a component to search a listing of
    files stored in folders. The text box to enter the search terms is
    coded to pass the following information:Name=

    <jeanne> State

    <jeanne> STATE_FOCUSABLE

    <jeanne> STATE_SELECTABLE

    <jeanne> example for embedded media player using WAI-ARIA

    <jeanne> A media player implements a slider to control the sound
    volume. The developer codes the component to pass the following
    information to the accessibility API:

    <jeanne> Name = Volume control

    <jeanne> Role = Slider

    <jeanne> States & Values

    <jeanne> aria-valuenow

    <jeanne> The slider’s current value.

    <jeanne> aria-value-min

    <jeanne> The minimum of the value range

    <jeanne> aria-value-max

    <jeanne> The maximum of the value range

    <jeanne> Description

    <jeanne> aria-describedby = 'Use the right or left arrow key to
    change the sound volume.'

    Does the phrase "rendered content, and alternative content" in the
    SC include generated content, or do we need to add that explicitly?

    <AllanJ> to me generated content comes from CSS

    <AllanJ> it probably should be explicitly included.

    <AllanJ> we had an item in UAAG10 concerning this.

    We can address it either in the SC explicitly or in the glossary
    entry for rendered content.

    <jeanne> ACTION: jeanne to Add "generated content" to the SC 2.1.2
    [recorded in
    [22]http://www.w3.org/2010/08/03-ua-minutes.html#action01]

    <trackbot> Created ACTION-419 - Add "generated content" to the SC
    2.1.2 [on Jeanne Spellman - due 2010-08-10].

    Kelly questions why 2.1.2 and 2.1.6 are separate.

    <AllanJ> UAAG10 css generated content is 6.9 it was a P2

Accessibility API reference

    <AllanJ> Microsoft's Active Accessibility (MSAA)
    msdn.microsoft.com/en-us/library/ms971310.aspx

    <AllanJ> User Interface (UI) Automation
    msdn.microsoft.com/en-us/library/ms747327.aspx

    <AllanJ> Gnome Accessibility Toolkit (ATK)
    library.gnome.org/devel/atk/

    <AllanJ> KDE Assistive Technology Service Provider Interface
    (AT-SPI) accessibility.kde.org/developer/atk.php

    <AllanJ> Mac Accessibility API
    [23]http://developer.apple.com/ue/accessibility/

      [23] http://developer.apple.com/ue/accessibility/

    <AllanJ> Iaccessible2
    accessibility.linuxfoundation.org/a11yspecs/ia2/docs/html/ ,
    www-03.ibm.com/able/open.../open_source_windows.html ,

    <AllanJ> Accessibility API Cross reference
    www.mozilla.org/access/platform-apis

    <AllanJ> PDF Accessibility API Reference
    www.adobe.com/devnet/acrobat/pdfs/access.pdf

2.1.5

    <jeanne> SC: 2.1.5 Write Access: If the user can modify the state or
    value of a piece of content through the user interface (e.g., by
    checking a box or editing a text area), the same degree of write
    access is available programmatically. (Level A)

    <jeanne> Intent for 2.1.1

    <jeanne> Computers, including many smart phones, have accessibility
    features built into the operating system. Some well-known APIs for
    the Windows operating system are: MSAA, iAccessible2, UIAutomation,
    [more]. Where ever technically possible, support the existing
    accessibility APIs.

    <jeanne> MT that was 2.1.1 sorry.

    <jeanne> Intent for 2.1.5

    <jeanne> If the user can affect the user interface using any form of
    input, the same affect may be done with assistive technologies. It
    is more reliable for the assistive technology to directly control
    the state, rather than having to simulate controls.

    <jeanne> Examples for 2.1.5:

    <jeanne> A volume control slider in a media player can be set
    directly to the desired value, e.g. the user can speak "Volume 35%".

    <jeanne> A set box with a tri-state value, e.g. "checked, unchecked
    and mixed" where the keystrokes are different to achieve the desired
    setting, depending on the state. The user can directly select the
    value when the control is programmatic.

    <kford> Possible revision to Intent:

    <kford> If the user can affect the user interface using any form of
    input, the same affect may be done through programatic access.

    <kford> It is often more reliable for the

    <kford> assistive technology to use the programatic method of access
    versus attempting to simulate mouse or keyboard input.

2.1.6 Properties

    2.1.6 Properties: If any of the following properties are supported
    by the accessibility platform architecture, make the properties
    available to the accessibility platform architecture: (Level A)

    * (a) the bounding dimensions and coordinates of rendered graphical
    objects

    * (b) font family of text

    * (c) font size of text

    * (d) foreground color of text

    * (e) background color of text.

    * (f) change state/value notifications

    * (g) selection

    * (h) highlighting

    * (i) input device focus

    * Intent of Success Criterion 2.1.6:

    These properties are all used by assistive technology to allow
    provide alternative means for the user to view or navigate the
    content, or to accurately create a view of the user interface and
    rendered content.

    * Examples of Success Criterion 2.1.61:

    • Kiara loads a new version of a popular web browser for the first
    time. She puts her screen reader into an "explore mode" that lets
    her review what is appearing on the screen. Her screen reader uses
    the bounding rectangle of each element to tell her that items from
    the menu bar all appear on the same horizontal line, which is below
    the window's title bar.

    • Kiara is using a screen reader at a telephone call center. The Web
    application displays caller names in different colors depending on
    their banking status. Kiara needs to know this information to
    appropriately respond to each customer immediately, without taking
    the time to look up their status through other means.

    • Max uses a screen magnifier that only shows him a small amount of
    the screen at one time. He gives it commands to pan through
    different portions of a Web page, but then can give it additional
    commands to quickly pan back to positions of interest, such as the
    text matched by the recent Search operation, text that he previously
    selected by dragging the mouse, or the text caret, rather than...

    scribe: having to manually pan through the document searching for
    them.

2.1.4

    <AllanJ> 2.1.4 Programmatic Availability of DOMs: If the user agent
    implements one or more DOMs, they must be made programmatically
    available to assistive technologies. (Level A)

    <AllanJ> • Intent of Success Criterion 2.1.4:

    <AllanJ> User agents (and other applications) and assistive
    technologies use a combination of DOMs, accessibility APIs, native
    platform APIs, and hard-coded heuristics to provide an accessible
    user interface and accessible content
    ([24]http://accessibility.linuxfoundation.org/a11yspecs/atspi/adoc/a
    11y-dom-apis.html). It is the user agents responsibility to expose
    all relevant content to the platform...

      [24] 
http://accessibility.linuxfoundation.org/a11yspecs/atspi/adoc/a11y-dom-apis.html).

    <AllanJ> ...accessibility api. Alternatively, the user agent must
    respond to requests for information from APIs.

    <AllanJ> • Examples of Success Criterion 2.1.4 :

    <AllanJ> In user agents today, an author may inject content into a
    web page using CSS (generated content). This content is written to
    the screen and the CSS DOM. The user agent does not expose this
    generated content from the CSS-DOM (as per CSS recommendation) to
    the platform accessibility API or to the HTML-DOM. This generated
    content is non-existent to an assistive technology user. The user
    agent...

    <AllanJ> ...should expose all information from all DOMs to the
    platform accessibility API.

    <AllanJ> A web page is a compound document containing HTML, MathML,
    and SVG. Each has a separate DOM. As the user moves through the
    document, they are moving through multiple DOMs. The transition
    between DOMs is seamless and transparent to the user and their
    assistive technology. All of the content is read and all of the
    interaction is available from the keyboard regardless of the
    underlying source...

    <AllanJ> ...code or the respective DOM.

    <AllanJ> • Related Resources for Success Criterion 2.1.4:

    <AllanJ> o www.w3.org/TR/SVG/svgdom.html

    <AllanJ> o www.w3.org/TR/MathML/chapter8.html

    <AllanJ> o www.w3.org/TR/DOM-Level-2-HTML/

    <AllanJ> o www.w3.org/TR/DOM-Level-2-Style/

    <AllanJ> o [25]https://developer.mozilla.org/en/gecko_dom_reference

      [25] https://developer.mozilla.org/en/gecko_dom_reference

    <AllanJ> o
    [26]http://developer.apple.com/mac/library/documentation/AppleApplic
    ations/Conceptual/SafariJSProgTopics/Tasks/DOM.html

      [26] 
http://developer.apple.com/mac/library/documentation/AppleApplications/Conceptual/SafariJSProgTopics/Tasks/DOM.html

    <AllanJ> o
    [27]http://msdn.microsoft.com/en-us/library/ms533050%28VS.85%29.aspx

      [27] http://msdn.microsoft.com/en-us/library/ms533050%28VS.85%29.aspx

    <AllanJ> o www.adobe.com/devnet/acrobat/pdfs/access.pdf

    <AllanJ> o www.w3.org/2004/CDF/

    <AllanJ> o dev.w3.org/2006/cdf/cdi-framework/

    <AllanJ> o www.w3.org/TR/CDR/

    Suggest changing "expose all relevant content to the platform
    accessibility API." to "expose all of its user interface and
    relevant content through the platform accessibility API, as this is
    the only approach which lets assistive technology interact with all
    software on the platform without having to implement separate
    solutions for each."

    Change "This content is written to the screen and the CSS DOM. The
    user agent does not" to merely "This content is written to the
    screen, but the user agent does not." as the generated content is
    not "written to" the CSS DOM, but rather it is written to the screen
    based on formatting instructions in the CSS, after it is parsed into
    the CSS DOM.

    Kelly and I both think the last sentence of the Intent can be
    removed.

    A key factor for 2.1.4 is that in many cases the DOM exposes richer
    content than can be exposed through the platform API. For example,
    the HTML DOM would expose attributes such as a link destination and
    whether or not it should be opened in a new window, which are not
    part of the generic set of properties that can be exposed through
    MSAA and equivalents.

    That is the real reason why the DOM needs to be exposed *in addition
    to* exposing content through the platform accessibility API.

    <kford> Accessibility APIs at some level are abstracting data from a
    more robust sourced.

    <AllanJ> i agree with the removal of the last sentence of the
    intent.

    <kford> A DOM will usually have more details than an API spe cific
    to accessibility can provide.

    <AllanJ> example: page with 5 links and text. UA loads all info into
    DOM, then it exposes (automatically or on request) to relevant
    sources (rendering engine, accessibiity api)

    <AllanJ> a11y api can ask what is at location x,y. or what are
    children of z element

    My comment above about 2.1.4 being about exposing the DOM in
    addition to platform API, that would change the ending of the first
    example, etc.

    <jeanne> close action-418

    <trackbot> ACTION-418 Copy proposals 3.1.4, 3.11 general intent,
    3.11.1 specific intent, 3.11.1,4 & 5 Examples, and 3.13.1 from
    minutes of 02-08-2010. Put in the Guidelines Master and the Survey
    for 5 August. closed

    <Kim> 4.6.3 Match Found: When there is a match, the user is alerted
    and the viewport moves so that the matched text content is at least
    partially within it. The user can search for the next instance of
    the text from the location of the match.

    <Kim> 4.6.3

    <Kim> Intent

    <Kim> It is important for the user to easily recognize where a
    search will start from.

    <Kim> Example: Jules is low vision and uses a magnified screen. She
    frequently searches for terms that appear multiple times in a
    document that contains a lot of repetition. It is important that the
    viewport moves after each search so she can easily track where she
    is in the document.

    <Kim> 4.6.4 Alert on No Match: The user is notified when there is no
    match or after the last match in content (i.e., prior to starting
    the search over from the beginning of content).

    <Kim> 4.6.4

    <Kim> Intent

    <Kim> It is important for users to get clear, timely feedback so
    they don't waste time waiting or, worse, issue a command based on a
    wrong assumption. It is important during a search that users are
    informed when there is no match or that the search has reached the
    beginning of the document.

    <Kim> Example:

    <Kim> Dennis uses a screen reader. As soon as he gets a message that
    there is no match he goes on to search for something else. If he
    does not get a message he wastes time retrying the search to make
    sure there is not a match.

    <Kim> 4.6.5 Advanced Find: The user agent provides an accessible
    advanced search facility, with a case sensitive and case-insensitive
    search option, and the ability for the user to perform a search
    within all content (including hidden content and captioning) for
    text and text alternatives, for any sequence of characters from the
    document character set.

    <Kim> 4.6.5

    <Kim> Intent:

    <Kim> Searching is much more useful when the user can specify
    whether case matters in a search and when the user can search
    alternative text.

    <Kim> Examples:

    <Kim> Dennis uses a screen reader. He wants to find all the
    instances of his friend Bill in a blog post about finances. He needs
    to specify case in order to avoid stopping at instances of "bill".
    Later, he searches for his friend's name in a blog post about poetry
    where the author never uses capital letters. In this instance he
    specifies that case does not matter.

    <Kim> Dennis he remembers a portion of a caption for something he
    had seen before that he wants to find. He needs to be able to search
    on the caption.

    Re 4.6.3 Intent, should address the portion of the SC about
    scrolling the window to show the match. That's important so that
    user's don't have to hunt through the document for the match. The SC
    doesn't really address "recognize where the search will start from",
    as it only provides that on successive searches, not the initial
    search.

    Re 4.6.3, it seems like this is one of those SC that is almost
    pointless, as it's hard to imagine a user agent not doing it
    already.

    <Kim> 4.6.3 rewritten Example: Jules is low vision and uses a
    magnified screen. She frequently searches for terms that appear
    multiple times in a document that contains a lot of repetition. It
    is important that the viewport moves and if necessary her screen
    scrolls after each search so she can easily track where she is in
    the document.

    Re 4.6.4 I think you should include the terrible results of real
    world cases where user agents don't do this: the user keeps
    searching through the document again and again, without realizing
    they're just seeing the same matches over and over again.

2.1.7 timely communication

    <kford> 2.1.7 Timely Communication: For APIs implemented to satisfy
    the requirements of this document, ensure that programmatic
    exchanges proceed at a rate such that users do not perceive a delay.
    (Level A).

    <kford> Intent: Conveying information for accessibility can often
    involve extensive communication between a user agent, an
    accessibility API, document object model and end user interaction.
    The objective is to ensure that the end user does not perceive a
    delay when interacting with the user agent.

    <kford> Example:

    <kford> Bonita accesses her web browser with a speech input program.
    She navigates to a web page and speaks the name of a link she wants
    to click. The link is activated with the same speed as it would be
    if a mouse had been used to click the link.

    <kford> Resources:

    <kford> Insert something about performance and classifications.

    <kford> Note: This changes wording of the SC slightly.

    <AllanJ> it drops the parenthetical (for non-web-based user agents)

    Re 2.1.7 Intent, the interaction also includes the assistive
    technology program.

    Re 2.1.7 Intent, you might end with something akin to: "Users would
    find a noticable delay between their key press and the response
    unacceptable, whether or not they are using assistive technology."

    <kford> Updated 2.1.7:

    <kford> 2.1.7 Timely Communication: For APIs implemented to satisfy
    the requirements of this document, ensure that programmatic
    exchanges proceed at a rate such that users do not perceive a delay.
    (Level A).

    <kford> Intent: Conveying information for accessibility can often
    involve extensive communication between a user agent, an
    accessibility API, document object model, assistive technology and
    end user interaction. The objective is to ensure that the end user
    does not perceive a delay when interacting with the user agent.

    <kford> Example:

    <kford> Bonita accesses her web browser with a speech input program.
    She navigates to a web page and speaks the name of a link she wants
    to click. The link is activated with the same speed as it would be
    if a mouse had been used to click the link.

    <kford> Resources:

    <kford> Insert something about performance and classifications.

    Another good example would be that a user press the tab key to move
    the focus to another button, his screen reader immediately says the
    name of that button, rather than making them wait for a second or
    two.

    <kford> Sounds good.

    <kford> Update again to 2.1.7

    <kford> 2.1.7 Timely Communication: For APIs implemented to satisfy
    the requirements of this document, ensure that programmatic
    exchanges proceed at a rate such that users do not perceive a delay.
    (Level A).

    <kford> Intent: Conveying information for accessibility can often
    involve extensive communication between a user agent, an
    accessibility API, document object model, assistive technology and
    end user interaction. The objective is to ensure that the end user
    does not perceive a delay when interacting with the user agent.

    <kford> Example:

    <kford> Bonita accesses her web browser with a speech input program.
    She navigates to a web page and speaks the name of a link she wants
    to click. The link is activated with the same speed as it would be
    if a mouse had been used to click the link.

    <kford> Arthur is browsing a web page with a screen reader. As he
    tabs from link to link, the text of each link instantly appears on
    his braille display.

    <kford> Resources:

    <kford> Insert something about performance and classifications.

    <AllanJ> kelly +1

4.1.12 Specify preferred keystrokes:

    <kford> Adding my text for this SC and such but don't want to ruin
    the dialog that's going on.

    <kford> 4.1.12 Specify preferred keystrokes:

    <kford> 4.1.12 Specify preferred keystrokes: The user can override
    any keyboard shortcut including recognized author supplied shortcuts
    (e.g accesskeys) and user interface controls, except for
    conventional bindings for the operating environment (e.g., for
    access to help). (Level AA)

    <kford> Intent:

    <kford> Some users may be able to hit certain keys on the keyboard
    with greater ease than others. Assistive technology software
    typically has extensive keyboard commands as well. The goal of this
    SC is to enable the user to be in control of what happens when a
    given key is pressed and use the keyboard commands that meet his or
    her needs.

    <kford> Example:

    <kford> Laura types with one hand and finds keys on the left side of
    the keyboard easier to press. She browses to a web page and notices
    that the author has assigned access keys using keys from the right
    side of the keyboard. She opens a dialog in the user agent and
    reassigns the access keys from the web page to the left side of the
    keyboard home row.

    <kford> Elaine's screen magnification program uses alt+m to increase
    the size of the magnified area of the screen. She notices that in
    her web browser, alt+m is a hotkey for activating a home button that
    stops her from being able to control her magnification software. She
    opens a hotkey reassignment feature in the user agent, and sets
    alt+o to be the new hotkey for the home button. Her screen...

    <kford> ...magnification software now works correctly.

    <AllanJ> Topic 3.13.1 again, new updates

    <AllanJ> • Intent of Success Criterion 3.13.1:

    <AllanJ> Users who use only the keyboard or screen readers need to
    be able to easily discover information about a link, including the
    title of the link, whether or not that link is a webpage, PDF, etc.
    and whether the link goes to a new page, opens a new user agent with
    a new page, or goes to a different location in the current page.
    This information allows the navigation of Web content quicker,...

    <AllanJ> ...easier, and with an expectation of what will happen upon
    link activation.

    <AllanJ> • Examples of Success Criterion 3.13.1:

    <AllanJ> • Robert, who uses a screen reader, needs to know whether a
    given link will automatically open in a new page or a new window.
    The browser indicates this information so he can discover it before
    he makes a decision to click on a link.

    <AllanJ> • Maria has an attention disorder, new windows opening are
    a large distraction. She needs to know whether a given link will
    automatically open in a new page or a new window. The browser
    indicates this information so she can decide not to follow a link
    that opens a new window.

    <jeanne> jeanne has put the 3.13.1 text into the document. I haven't
    done the earlier ones yet.

    <jeanne> close action-419

    <trackbot> ACTION-419 Add "generated content" to the SC 2.1.2 closed

    <kford> Anyone have an opinon on my text?

    <AllanJ> good stuff kelly

    <jeanne> ACTION: jeanne to update document and survey with Kim's
    droaft of 4.6.3, 4.6.4, 4.6.5 (see rewrites) [recorded in
    [28]http://www.w3.org/2010/08/03-ua-minutes.html#action02]

    <trackbot> Created ACTION-420 - Update document and survey with
    Kim's droaft of 4.6.3, 4.6.4, 4.6.5 (see rewrites) [on Jeanne
    Spellman - due 2010-08-10].

    <jeanne> ACTION: jeanne to update document with Kford's draft of
    4.1.12 from minutes
    [29]http://www.w3.org/2010/08/03-ua-minutes.html#item10 recorded in
    [30]http://www.w3.org/2010/08/03-ua-minutes.html#action03]

    <trackbot> Created ACTION-421 - Update document with Kford's draft
    of 4.1.12 from minutes
    [31]http://www.w3.org/2010/08/03-ua-minutes.html#item10 on Jeanne
    Spellman - due 2010-08-10].

    Kim and I were normalizing terminology related to "focus" in 3.11,
    and are ready to begin writing Intent and Examples (a few are done).
    Our work in progress is in
    [32]https://docs.google.com/Doc?docid=0ASiGLIaAlHSKZGR3d3FrbWJfMjMzZ
    HJtemhuY3o&hl=en

      [32] 
https://docs.google.com/Doc?docid=0ASiGLIaAlHSKZGR3d3FrbWJfMjMzZHJtemhuY3o&hl=en

3.13.1 & 2

    <AllanJ> Problems with 3.13.1.

    <AllanJ> SC wording

    <AllanJ> 3.13.1 Basic Link Information: The following information is
    provided for each link (Level A):

    <AllanJ> • (a) link element content,

    <AllanJ> • (e) new viewport: whether the author has specified that
    the resource will open in a new viewport.

    <AllanJ> Should ‘link’ be ‘anchor’, to differentiate from the
    ‘link’ in the HTML <head>

    <AllanJ> Anchor (Link) element content includes ‘href’, ‘title’,
    ‘target’ (opening in a new window), ‘hreflang’ (language of the
    destination page), protocol (from the href), destination file type
    (from the href), character set of the destination page. If we
    include all of these as part of ‘link element content’ the SC will
    overlap all of 3.13.2. Since all of the information is...

    <AllanJ> ...available to the UA,...

    <AllanJ> ...suggest removing 3.13.2. If the developers will go to
    the effort of exposing the target (new window) they can do all of
    them.

3.11

    Kim and I were normalizing terminology related to "focus" in 3.11,
    and are ready to begin writing Intent and Examples (a few are done).
    Our work in progress is in
    [33]https://docs.google.com/Doc?docid=0ASiGLIaAlHSKZGR3d3FrbWJfMjMzZ
    HJtemhuY3o&hl=en

      [33] 
https://docs.google.com/Doc?docid=0ASiGLIaAlHSKZGR3d3FrbWJfMjMzZHJtemhuY3o&hl=en

Summary of Action Items

    [NEW] ACTION: jeanne to Add "generated content" to the SC 2.1.2
    [recorded in
    [34]http://www.w3.org/2010/08/03-ua-minutes.html#action01]
    [NEW] ACTION: jeanne to update document and survey with Kim's droaft
    of 4.6.3, 4.6.4, 4.6.5 (see rewrites) [recorded in
    [35]http://www.w3.org/2010/08/03-ua-minutes.html#action02]
    [NEW] ACTION: jeanne to update document with Kford's draft of 4.1.12
    from minutes [36]http://www.w3.org/2010/08/03-ua-minutes.html#item10
    [recorded in
    [37]http://www.w3.org/2010/08/03-ua-minutes.html#action03]

    [End of minutes]
Received on Tuesday, 3 August 2010 22:17:36 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:49:39 UTC