Minutes of Day 1 of UAWG F2F

MInutes: http://www.w3.org/2013/08/27-ua-minutes.html


Text of Minutes

    [1]W3C

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

                                - DRAFT -

     User Agent Accessibility Guidelines Working Group Teleconference

27 Aug 2013

    See also: [2]IRC log

       [2] http://www.w3.org/2013/08/27-ua-irc

Attendees

    Present
    Regrets
    Chair
           Jim & Kelly

    Scribe
           kford, JR, Jan, greg, allanj

Contents

      * [3]Topics
          1. [4]OCAD 48 5.1.2
          2. [5]OCAD 46 4.1.6
          3. [6]OCAD45 re 4.1.5
          4. [7]OCAD43 re 3.4.1
          5. [8]OCAD39 re 2.11.8
          6. [9]OCAD34 and OCAD35, re 2.10.1 and 2.10.2
          7. [10]OCAD33 re 2.9.2
          8. [11]OCAD31 re 2.8.1
          9. [12]OCAD27 re 2.6.1 Access to input methods
         10. [13]OCAD26 re 2.5.3
         11. [14]OCAD25 re 2.5.2
         12. [15]OCAD24 re 1.10.2
         13. [16]OCAD22 re 2.3.5
         14. [17]OCAD16 re 2.1.4
      * [18]Summary of Action Items
      __________________________________________________________

    <trackbot> Date: 27 August 2013

    <jeanne> meeting: UAWG F2F

    <kford> Scribe: kford

    <Jan> [19]http://www.w3.org/WAI/UA/UAAG20/

      [19] http://www.w3.org/WAI/UA/UAAG20/

    <Jan> [20]http://www.w3.org/WAI/UA/2013/commentsWD.html

      [20] http://www.w3.org/WAI/UA/2013/commentsWD.html

OCAD 48 5.1.2

    Group talking about different locations for this point.

    Group sees some value in moving standards compliance earlier

    Group talking about numbering.

    And perceived importance.

    KP: We covered some of the suggestions around standards in the
    last editorial pass.

    Resolution: Groupdecided to leave 5.1.2 as is and OCAD is
    closed.

OCAD 46 4.1.6

    <Jan> ACTION: Jeanne to check capitalization of handle of 5.1.2
    and 5.1.3 [recorded in
    [21]http://www.w3.org/2013/08/27-ua-minutes.html#action01]

    <trackbot> Created ACTION-870 - Check capitalization of handle
    of 5.1.2 and 5.1.3 [on Jeanne F Spellman - due 2013-09-03].

    JA 4.1.6 is related onscreen text

    <AllanJ> 4.1.6 OCAD46

    <AllanJ> proposal not accepted. 416 items are related to
    onscreen text.

    <AllanJ> 412 are related to user interface components that have
    a name, role, state.

    GL: 4.1.6 K seems a bit quirksome.

    Group talks about history.

    JAN: Going to be hard to find implamentations.

    More discussion from GL and JR if parts of 4.1.6 are to
    platform specific.

    More discussion about separating 4.1.2 and 4.1.6

    JR: We do this separation in speech.

    JR reads from what we have in the doc around speech.

    JR: The speech model is an understandable model.

    KP I agree

    Discussion about keeping them separate, similar to what we do
    with speech synthesis.

    JR now describing how ATAG conveys similar info from this area.

    KP asking if 4.1.1 covers this info.

    KP asking if 4.1.1 covers this info.Selection and focus are
    really important. They shuld be moved to 4.1.2 and then move
    leave 4.1.6

    <Jan> 4.1.2 Expose basic properties: For all user interface
    components including user interface, rendered content,
    generated content, and alternative content, the user agent
    makes available the following, via a platform accessibility
    service: (a) name, (b) role, (c) state, (d) value, (e)
    selection, (f) focus. (Level A)

    Group working on reworiding for 4.1.2 and 4.1.6

    <Jan> 4.1.2 Expose basic properties: For all user interface
    components including the user agent user interface, rendered
    content, generated content, and unrendered alternative content,
    the user agent makes available the following, via a platform
    accessibility service: (a) name, (b) role, (c) state, (d)
    value, (e) selection, (f) focus. (Level A)

    <Jan> 4.1.2 Expose basic properties: For all user interface
    components including the user agent user interface, rendered
    content, and generated content, the user agent makes available
    the following, via a platform accessibility service: (a) name,
    (b) role, (c) state, (d) value, (e) selection, (f) focus.
    (Level A)

    <Jan> 4.1.2 Expose basic properties: For all user interface
    components including the user agent user interface, rendered
    content, and generated content, the user agent makes available
    the following, via a platform accessibility service: (a) name,
    (b) role, (c) state, (d) value, (e) selection, (f) focus.
    (Level A)

    <Jan> 4.1.2 Expose basic properties: For all user interface
    components, including the user agent user interface, rendered
    content, and generated content, the user agent makes available
    the following, via a platform accessibility service: (a) name,
    (b) role, (c) state, (d) value, (e) selection, (f) focus.
    (Level A)

    <Jan> 4.1.6 Expose additional properties: For all user
    interface components, including the user agent user interface,
    rendered content, and generated content, the user agent makes
    available the following, via a platform accessibility service,
    if the properties are supported by the service: (a) the
    bounding dimensions and coordinates of onscreen elements, (b)
    font family of text, (c) font size of...

    <Jan> ...text, (d) foreground color of text, (e) background
    color of text, (f) highlighting, (g) keyboard commands. (Level
    AA)

    <Jan> 4.1.6 Expose additional properties: For all user
    interface components, including the user agent user interface,
    rendered content, and generated content, the user agent makes
    available the following, via a platform accessibility service,
    if the properties are supported by the service: (a) the
    bounding dimensions and coordinates of onscreen elements, (b)
    font family of text, (c) font size of...

    <Jan> ...text, (d) foreground color of text, (e) background
    color of text, (f) highlighting, (g) keyboard commands. (Level
    AA)

    <Jan> 4.1.6 Expose additional properties: For all user
    interface components, including the user agent user interface,
    rendered content, and generated content, the user agent makes
    available the following, via a platform accessibility service,
    if the properties are supported by the service: (a) the
    bounding dimensions and coordinates of onscreen elements, (b)
    font family of text, (c) font size of...

    <Jan> ...text, (d) foreground and background colors for text,
    (e) highlighting, (f) keyboard commands. (Level AA)

    <Jan> 4.1.6 Expose Additional Properties: For all user
    interface components, including the user agent user interface,
    rendered content, and generated content, the user agent makes
    available the following, via a platform accessibility service,
    if the properties are supported by the service: (a) the
    bounding dimensions and coordinates of onscreen elements, (b)
    font family of text, (c) font size of...

    <Jan> ...text, (d) foreground and background colors of text,
    (e) highlighting, (f) keyboard commands. (Level AA)

    <Jan> 4.1.2 Expose Basic Properties: For all user interface
    components, including the user agent user interface, rendered
    content, and generated content, the user agent makes available
    the following, via a platform accessibility service: (a) name,
    (b) role, (c) state, (d) value, (e) selection, (f) focus.
    (Level A)

    <Jan> 4.1.6 Expose Additional Properties: For all user
    interface components, including the user agent user interface,
    rendered content, and generated content, the user agent makes
    available the following, via a platform accessibility service,
    if the properties are supported by the service: (a) the
    bounding dimensions and coordinates, (b) font family of text,
    (c) font size of text, (d) foreground...

    <Jan> ...and background colors of text, (e) highlighting, (f)
    keyboard commands. (Level AA)

    <Jan> 4.1.6 Expose Additional Properties: For all user
    interface components, including the user agent user interface,
    rendered content, and generated content, the user agent makes
    available the following, via a platform accessibility service,
    if the properties are supported by the service: (a) bounding
    dimensions and coordinates, (b) font family of text, (c) font
    size of text, (d) foreground and...

    <Jan> ...background colors of text, (e) highlighting, (f)
    keyboard commands. (Level AA)

    <scribe> Scribe: JR

    <Jan> Scribe: Jan

    Resolution: All agree to use "4.1.2 Expose Basic Properties:
    For all user interface components, including the user agent
    user interface, rendered content, and generated content, the
    user agent makes available the following, via a platform
    accessibility service: (a) name, (b) role, (c) state, (d)
    value, (e) selection, (f) focus. (Level A) "
    ... All agree to use "4.1.6 Expose Additional Properties: For
    all user interface components, including the user agent user
    interface, rendered content, and generated content, the user
    agent makes available the following, via a platform
    accessibility service, if the properties are supported by the
    service: (a) bounding dimensions and coordinates, (b) font
    family of text, (c) font size...
    ... of text, (d) foreground and background colors of text, (e)
    highlighting, (f) keyboard commands. (Level AA)"

    <jeanne>
    [22]http://www.w3.org/WAI/UA/2013/ED-UAAG20-20130827/MasterUAAG
    20130827.html

      [22] 
http://www.w3.org/WAI/UA/2013/ED-UAAG20-20130827/MasterUAAG20130827.html

    <jeanne> todays Master document <-
    [23]http://www.w3.org/WAI/UA/2013/ED-UAAG20-20130827/MasterUAAG
    20130827.html

      [23] 
http://www.w3.org/WAI/UA/2013/ED-UAAG20-20130827/MasterUAAG20130827.html

    <Admin> 4.1.6 add to end of Intent:

    <Admin> Keyboard commands include direct keyboard commands
    (e.g. Control-f to select the find box) and keyboard sequences
    (e.g. Alternate-f, to call up the File menu and select Save
    As).

    Definition of: user interface

    For the purposes of UAAG 2.0, *user interface* includes both:

    - the *user agent user interface*: the controls (e.g. menus,
    buttons, prompts, and other components for input and output)
    and mechanisms (e.g. selection and focus) provided by the user
    agent ("out of the box") that are not created by content.

    - the *content user interface*: the renderings created from the
    content, such as text, images, form controls, links, and
    applets.

    The document distinguishes them only where required for
    clarity.

    The term *user interface control* refers to a component of the
    user agent user interface or the content user interface,
    distinguished where necessary.

    <AllanJ> user agent user interface should include extensions
    that become part of the user agent user interface (e.g.
    toolbars, additional menus, etc.)

    <kford> RRSAgent: JA: Explain the difference between 4.1.1 and
    5.1.3

    <kford> JA: Explain the difference between 4.1.1 and 5.1.3

    <greg> scribe: greg

    Jan: 5.1.3 is about UI design, whereas the 4.1 is about
    exposing things to assistive technology.

    Resolution: 4.1.2 and 4.1.6 are done, having moved some bullet
    items from .6 to .2, reduced priority of .6 to AA, and done
    significant wordsmithing.

    <jeanne> #1 of user interface: the user agent user interface,
    the controls (e.g. menus, buttons, prompts, and other
    components for input and output) and mechanisms (e.g. selection
    and focus) provided by the user agent ("out of the box") that
    are not created by content. The user agent user interface also
    includes extensions that become part of the user agent user
    interface (e.g. toolbars, additional menus,

    <jeanne> etc.)

OCAD45 re 4.1.5

    re 4.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)

    OCAD45: Still isn't possible for ARIA as far as I know.

    <AllanJ> This is unrelated to ARIA. it is only to allow AT to
    write to the interface the same way a user can when using a
    mouse or keyboard.

    Jan: It is related to ARIA because UI means both UA UI and
    rendered content.
    ... When an element's state is set using a script, it sets the
    ARIA state, causing the UA to set a state in the platform API.
    ... Joseph says that for Javascript-drawn checkbox, if you
    change its state using MSAA the UA does not correctly
    communicate this to the author's javascript, because it's not
    due to a Check Event.

    <AllanJ> is this another case of javascript being a blackhole,
    it is unrecognized by user agent or msaa?

    Greg: Is that a UA bug?

    Jan: More that everything hasn't been worked out yet.

    Greg: If AT uses MSAA to check a checkbox, the UA should map
    that to an event such as click that it can send to the script,
    thus hiding the fact that it was not done by a user with a real
    input device.

    Jeanne: Seems really important.

    Jim: Seems to fall into the broad category of javascript
    problems.

    Kelly: It will always be the case that there are situations
    where things cannot be done programmatically.

    Greg: It's important to ensure that AT can be used to edit
    content and driving UI the same was as mouse or keyboard, and
    we do want to support platform API as the method so that AT can
    be written to be app-neutral.

    Jan: It isn't worded to require platform API, just some
    programmatic method.

    Kelly: Can we take ARIA out of the equation?

    Jan: Gmail is an example of a complex script that keeps lots of
    its own state information.
    ... Browser has no problem changing state of a checkbox...

    Kelly: the browser should expect read and write to everything
    through the platform API.

    Jan: Agreed.

    Kelly: Thus ARIA seems irrelevant here.

    Jan: Just calling out that ARIA does not solve the write-access
    part of the problem.
    ... Using ARIA the UA and AT know this element acts as a
    checkbox...
    ... ...maybe this is fine, and authors just need to catch up.

    Kelly: I'd leave this, despite implementation questions.

    Jan: Just wanted to call this out as an issue.

    <AllanJ> +1 leaving it as is

    Kelly: I want to find out what Chrome and other UA do, what
    events are bubbled to scripts when element state is changed
    programmatically.
    ... The general requirement is still true, this general state
    is what we need, we assume recognized part is covered somewhere
    else (at a high level)...

    Greg: Despite the wording of the comment, this is not about
    ARIA but about whether scripts get notified and *can* handle it
    correctly when element state is changed programmatically by
    anything other than the script itself.

    Jan: Correct.

    Kelly: I think we're okay on this.

    Resolution: No change. The general requirement is still true.
    Scripts need to be notified by the browser when element state
    is changed, including changed programmatically.

OCAD43 re 3.4.1

    3.4.1 Avoid unpredictable focus: The user can prevent focus
    changes that are not a result of explicit user request. (Level
    A)

    OCAD43: This seems like the superset (and so the possible
    replacement) of 1.8.9 and 2.1.4.

    1.8.9 Open on Request: The user can specify whether author
    content can open new top-level viewports (e.g. windows or
    tabs). (Level AA)

    2.1.4 Separate Selection from Activation: The user can specify
    that focus and selection can be moved without causing further
    changes in focus, selection, or the state of controls, by
    either the user agent or author content. (Level A)

    <AllanJ> agree that 3.4.1 is the more general case that
    includes 1.8.9 (189 should be removed) and is only about focus
    changes. except 189 allows configuration??

    <AllanJ> 2.1.4 is about change in state of selection for radio
    buttons and checkboxes when an item receives focus. this is
    different than moving focus in an unpredictable manner. 2.1.4
    should remain as is.

    Jim: Agreed 3.1.4 is a more general case that includes 1.8.9,
    the latter could be removed, except 1.8.9 allows configuration
    as well.
    ... opening a new viewport changes focus...

    Greg: Opening a new viewport may not change focus, based on UA
    configuration as well as scripted behaviors.

    Jan: 3.4.1 is alone in 3.4 which is about predictable
    behaviors. Could anything else fit there?

    Greg: Examples of unpredictable behavior might include changing
    visible portion when window resized, random tab order when not
    specified by author, allowing scripts to close windows or tabs,
    etc.

    Kim: Tons of examples for 3.4.1 in the Implementing document.
    Most along the Perceivable lines.

    Jan: 1.8.9 and 2.1.4 are separate enough that they deserves to
    live.

    Kim: Each is necessary in its context, fitting in and
    contributing to the SC around them.

    <AllanJ> leaving these alone seems fine to me.

    <AllanJ> does no harm currently.

    Greg: We could leave it for now; if Jan finds a better way to
    combine or reorganize later he can submit that, but it seems we
    could move on for now.

    Jan: Goal is to streamline and shorten the document, and
    prevent readers from being turned off by perceived repetition.

    Kelly: two questions: does experience say this will be a
    problem, and what's the cost of message around with it at this
    point.

    Jan: if we felt 3.4.1 was completely covered by 2.1.4, we could
    safely remove it and not lose anything, combine the examples,
    etc.

    Kim: That would be better, taking out the one that has no
    context would be better than taking out either of the two
    others.

    Jeanne: Think these need to stay so that we don't lose the
    whole "unpredictable" part.

    Resolution: Keep 3.4.1, 2.1.4, and 1.8.9 as are for now; Jan
    may come back with proposal later.

OCAD39 re 2.11.8

    2.11.8 Track Enable/Disable of Time-Based Media: During
    time-based media playback, the user can determine which tracks
    are available and select or deselect tracks, overriding global
    default settings, such as captions or audio descriptions.
    (Level AA)

    OCAD39: Both the examples in the implementing document are
    taken care of by something in GL1.1? So perhaps this can be
    removed.

    <Jan>
    [24]http://lists.w3.org/Archives/Public/w3c-wai-ua/2013JulSep/0
    039.html

      [24] 
http://lists.w3.org/Archives/Public/w3c-wai-ua/2013JulSep/0039.html

    Jim: 2.11.8 is covered by 1.1.1 and is an implementation
    detail. remove 2.11.8 add example to 1.1.1 Betty, has an
    auditory processing problem. she is watching a movie that has
    several caption and audio tracks . She pulls up a menu to
    determine which is available she switches between audio tracks
    until she find one she can understand. She also reinforces the
    audio by selecting a caption track.

    <Jan> 1.1.1 Render Alternative Content: The user can choose to
    render any type of recognized alternative content that are
    present for a content element. (Level A)

    1.1.1 Render Alternative Content: The user can choose to render
    any type of recognized alternative content that are present for
    a content element. (Level A)

    Greg: They are not the same as 1.1.1 is about all forms of
    tracks, whereas 2.11.8 is just alternative content.
    ... Neither is a subset of the other.

    Jan: Our media player handles enabling/disabling alternative
    content tracks, but not other tracks, so should it fail?

    Greg: A use case a is if a video had a dialog track and a music
    track, for example, a person with impaired hearding or
    cognition may need to disable the background noises in order to
    understand the speech.

    Jan: Our tool should never be able to meet AA compliance then?

    Greg: We're saying that right now such a tool meets A but not
    AA because it doesn't let the user choose to disable arbitrary
    tracks.
    ... Another use case is my former coworker who had seizures
    triggered by low-level sounds such as white noise, and so had
    to turn off any audio that included fountains, surf, and the
    like.

    Jan: 2.11.8 is semi-redundant to 1.5.1 Global Volume, which
    lets the user turn down (off) audio tracks. However, it doesn't
    handle differenent video tracks.

    Jan interprets the SC as about alternative content, whereas
    Greg interpreted it as being about tracks in general. Greg
    emphasized "tracks", while Jan emphasized "such as captions and
    audio description".

    Jan: Greg's two use cases would be covered by 1.5.1.

    <Jan> Jan: Any concerns about audio track levels is handled by
    1.5.1 Global Volume: The user can adjust the volume of each
    audio tracksindependently of other tracks, relative to the
    global volume level set through operating environment
    mechanisms. (Level A)

    <jeanne> ACTION: jeanne to move examples from 2.11.8 to 1.1.1
    and remove 2.11.8 [recorded in
    [25]http://www.w3.org/2013/08/27-ua-minutes.html#action02]

    <trackbot> Created ACTION-871 - Move examples from 2.11.8 to
    1.1.1 and remove 2.11.8 [on Jeanne F Spellman - due
    2013-09-03].

    Decided that we don't need 2.11.8's ability to disable video
    tracks, because the only important use cases we come up with
    involve alternative media, which are covered by 1.1.1.

    The important use cases regarding non-alternative audio tracks
    are covered by 1.5.1.

    Resolution: Delete 2.11.8 and move its examples and intent to
    1.1.1.
    ... Add to 1.5.1 Examples the use case above about a person who
    has seizures triggered by low-level sounds such as white noise,
    and so has to turn off any audio that included fountains, surf,
    and the like.

    <AllanJ> example: Betty, has an auditory processing problem.
    she is watching a movie that has several caption and audio
    tracks . She pulls up a menu to determine which is available
    she switches between audio tracks until she find one she n

    <AllanJ> understand. She also reinforces the audio by selecting
    a caption track.

    <jeanne> ACTION: Jeanne to add Betty example from Jim's email
    of 27 August 2013 to 1.1.1 [recorded in
    [26]http://www.w3.org/2013/08/27-ua-minutes.html#action03]

    <trackbot> Created ACTION-872 - Add betty example from jim's
    email of 27 august 2013 to 1.1.1 [on Jeanne F Spellman - due
    2013-09-03].

OCAD34 and OCAD35, re 2.10.1 and 2.10.2

    2.10.1 Three Flashes or Below Threshold: In its default
    configuration, the user agent does not display any user
    interface components or recognized content that flashes more
    than three times in any one-second period, unless the flash is
    below the general flash and red flash thresholds. (Level A)

    2.10.2 Three Flashes: In its default configuration, the user
    agent does not display any user interface components or
    recognized content that flashes more than three times in any
    one-second period (regardless of whether not the flash is below
    the general flash and red flash thresholds). (Level AAA)

    OCAD34: (Re 2.10.1) This is good for the User Agent UI, but
    hard to automatically determine in playing content. Perhaps
    2.11.1 handles this?

    OCAD35: (Re 2.10.2) Could this also then be removed? (related
    to comment OCAD34)

    <AllanJ> jim's proposal: remove 2.10.1 and promote 2.10.2 to A
    (UI should not be doing this anyway, no browser does this so
    easy check), and change wording of 2.10.2 to : 2.10.2 Three
    Flashes: In its default configuration, the user agent does not
    display any user interface components that flashes more than
    three times in any one-second period (regardless of whether not
    the flash is below the general...

    <AllanJ> ...flash and red flash thresholds). (Level A) [removed
    'or recognized content' and changed level from AAA to A]

    <AllanJ> or keep 2.10.2 at AAA but still change wording. and
    keep 2.10.1 but change wording to

    <AllanJ> 2.10.1 Three Flashes or Below Threshold:In its default
    configuration, the user agent does not display any user
    interface components that flashes more than three times in any
    one-second period, unless the flash is below general flash and
    red flash thresholds. (Level A) [removed "or recognized
    content"]

    Greg: I'd just cut out the "or rendered content" from both.

    Jan: A person who needs to avoid flashing already has the
    ability to avoid videos until they approve them.

    Resolution: remove "or recognized content" from 2.10.1 and
    2.10.2.

OCAD33 re 2.9.2

    2.9.2 Retrieval Progress: By default, the user agent shows the
    progress of content retrieval. (Level A)

    OCAD33: I think this is in the wrong GL, it doesn't allow
    time-independent interaction

    <Kim> addition to intent of 2.10.1 and 2.10.2:

    <Kim> It's recommended that this also be applied to recognized
    content.

    <AllanJ> jim's comment -

    <AllanJ> Agree, this is not about time independence. the
    download monitor is informing the user of what is happening.
    seems better in Understandable (GL4).

    <AllanJ> however,

    <AllanJ> Every browser does this. informing the user about
    downloading status is basic usability; as long as the download
    monitor is programatically accessible and its messaging is
    accessible as per our other guidelines. Proposal Delete it.

    Greg: Some browsers (e.g. Blackberry browser) don't tell you
    how much is being downloaded, just that *something* is being
    downloaded.

    Kelly: Recommend deleting this SC.

    Kim: For some people with disabilities its much more difficult
    if they have to start over. especially if they thought it was
    necessary when it wasn't.
    ... I've watched users go around and around and around trying
    it over and over again, which can use up their entire day's
    maximum amount of typing.

    Kelly: The examples included don't make a sufficient case for
    differential benefit for people with disabilities.

    Jim: The original comment was that this was in the wrong SC,
    but couldn't find a good place for it under Perceivable.

    Kelly: Willing to keep it if we move it and give it a more
    compelling example.

    Greg: I think it's important to clarify what this requires:
    does it mean percent complete, or it it enough to distinguish
    between "done" and "not yet done"?

    Kelly: Another reason for keeping it is that one often has a
    limited number of times you can ask for help.

    Jan: Like the idea of phrasing it as "state of content
    retrieval activity", rather than "progress of content
    retrieval".

    Greg: Should this also be about processing/rendering, as
    opposed to just about downloading? For example if the knows the
    page is still being rendered and so is still running and not
    yet ready to accept input, should the user be told?

    Jim: Propose keep the SC but move to 3.2, and add a new example
    that Kim will write.

    Resolution: Keep SC 2.9.2 but move to 3.2, and add a new
    example that Kim will write.

OCAD31 re 2.8.1

    <AllanJ> jim's comment: proposal. leave it. it was many SC,
    they were combined because they all interrelated and built upon
    each other.

    2.8.1 Customize display of controls representing user interface
    commands, functions, and extensions: The user can customize
    which user agent commands, functions, and extensions are
    displayed within the user agent's user interface as
    follows:(Level AA) (a) Show: The user can choose to display any
    controls available within the user agent user interface,
    including user-installed extensions. It...

    scribe: is acceptable to limit the total number of controls
    that are displayed onscreen. (b) Simplify: The user can
    simplify the default user interface by choosing to display only
    commands essential for basic operation (e.g. by hiding some
    control). (c) Reposition: The user can choose to reposition
    individual controls within containers (e.g. Toolbars or tool
    palettes), as well as reposition the...
    ... containers themselves to facilitate physical access (e.g.
    To minimize hand travel on touch screens, or to facilitate
    preferred hand access on handheld mobile devices). (d) Assign
    Activation Keystrokes or Gestures: The user can choose to view,
    assign or change default keystrokes or gestures used to
    activate controls. (e) Reset: The user has the option to reset
    the containers and controls...
    ... to their original configuration.

    OCAD31: This SC is probably twice as long as the next biggest.
    Has a different feel.

    <AllanJ> jim's comment: proposal. leave it. it was many SC,
    they were combined because they all interrelated and built upon
    each other.

    Jan: Okay with that.

    <Kim> Extra example for 2.9.2 which is going to be moved to 3.2
    Larry has severe repetitive strain injuries and is limited to
    typing for only a short period of time every day. He downloads
    a long document, and is surprised to see that the download is
    progressing slowly. He periodically checks the progress bar
    rather having to type to repeatedly check to see if it's done.

    Jan: Recognize it would be a lot of work to split 2.8.1 back
    into multiple SC, along with their Examples, etc.
    ... Odd to use "GUI" in the Guideline's title.

    Jeanne: Will change that to "graphical" controls.

    <jeanne> ACTION: jeanne to go through the guidelines and remove
    any period at the end of a guideline. [recorded in
    [27]http://www.w3.org/2013/08/27-ua-minutes.html#action04]

    <trackbot> Created ACTION-873 - Go through the guidelines and
    remove any period at the end of a guideline. [on Jeanne F
    Spellman - due 2013-09-03].

    (The group worked on and incorporated Kim's new example for
    showing status of retrieval progress.)

OCAD27 re 2.6.1 Access to input methods

    2.6.1 Access to input methods: The user can discover recognized
    input methods explicitly associated with an element, and
    activate those methods in a modality independent manner. (Level
    AA)

    OCAD27: User can discover?

    <AllanJ> jim's proposal: 2.6.1 Access to input methods: The
    user can have presented any recognized input methods explicitly
    associated with an element, and activate those methods in a
    modality independent manner.

    Kim: "the user can have presented" is ambiguous language, as it
    could be misread as "the user can have (themselves) presented"
    as opposed to "the user can have presented (to them)".

    Greg: "The user can determine which input methods" or "The user
    can identify the input methods"?

    Kelly: Can't say "the user can" as the UA doesn't know what the
    user is and is not capable of perceiving. The SC can't test the
    user.

    <Kim> The user agent provides a means for the user to determine
    recognized input methods explicitly associated with an element,
    and a means for the user to activate those methods in a
    modality independent manner.

    Resolution: Change 2.6.1 to read "The user agent provides a
    means for the user to determine recognized input methods
    explicitly associated with an element, and a means for the user
    to activate those methods in a modality independent manner."

OCAD26 re 2.5.3

    2.5.3 Configure Elements for Structural Navigation: The user
    can configure sets of important elements (including element
    types) for structured navigation and hierarchical/outline view.
    (Level AAA)

    OCAD26: "configure sets of" implies ability to create multiple
    sets

    <AllanJ> jim's comment: this is level AAA, I know of no UA that
    does this. Suspect it will be eliminated because of lack of
    implementation.

    <AllanJ> Proposal: reword (make it singular)

    <AllanJ> 2.5.3 Configure Elements for Structural Navigation:
    The user can configure a set of important elements (including
    element types) for structured navigation and
    hierarchical/outline view.

    Resolution: Change 2.5.3 to read "2.5.3 Configure Elements for
    Structural Navigation: The user can configure a set of
    important elements (including element types) for structured
    navigation and hierarchical/outline view. (AAA)"

OCAD25 re 2.5.2

    2.5.3 Configure Elements for Structural Navigation: The user
    can configure sets of important elements (including element
    types) for structured navigation and hierarchical/outline view.
    (Level AAA)

    2.5.2 Navigate by structural element: The user agent provides
    at least the following types of structural navigation, where
    the structure types exist:(Level AA) (a) by heading (b) within
    tables

    OCAD25: How is this related to 1.10.1?

    <AllanJ> jim's comment: proposal: remove reference for 2.5.2 in
    Related resources for 1.10.1

    Resolution: from "2.5.1 Location in Hierarchy" Remove from
    1.10.1 Related Resources.

OCAD24 re 1.10.2

    Jan: This reference wasn't actually in 1.10.2 any more, so this
    is moot.

    Jim: But also propose deleting 1.10.2.

    2.5.2 Navigate by structural element: The user agent provides
    at least the following types of structural navigation, where
    the structure types exist:(Level AA) (a) by heading (b) within
    tables

    <Jan> 1.10.2 Access to Element Hierarchy: The user can
    determine the path of element nodes going from the root element
    of the element hierarchy to the currently focused or selected
    element. (Level AAA)

    Starting over...

    <Jan> 2.5.1 Location in Hierarchy: When the user agent is
    presenting hierarchical information, but the hierarchy is not
    reflected in a standardized fashion in the DOM or platform
    accessibility services, the user can view the path of nodes
    leading from the root of the hierarchy to a specified element.
    (Level AA)

    1.10.2 Access to Element Hierarchy: The user can determine the
    path of element nodes going from the root element of the
    element hierarchy to the currently focused or selected element.
    (Level AAA)

    The question is, are these redundant to each other?

    Greg: I thought the distinction was that one was about
    hierarchy of nodes in the DOM, the other was about hierarchy of
    information NOT in the DOM such as artists, albums, etc. in a
    media library.

    2.5.1 is iTunes Library (for example), 1.10.2 is the DOM.

    Agreement that they read confusingly similarly.

    Greg: I believe this was originally Simon's SC.
    ... I would not object to deleting 2.5.1, as it's only AAA.

    Jim: The comment was that they seemed to be the same, but
    discussion reveals they are very different. The question of
    whether 2.5.1 should stay, or be reworded, or deleted, is an
    open issue.

    Jan: If we as a group had trouble understanding it, it is
    potentially a problem.
    ... the original OCAD comment was very minor, only about a
    problem in the IER.

    <Jan> ACTION: Jan to look at 2.5.1 Location in Hierarchy
    including possibly to check in with Simon. [recorded in
    [28]http://www.w3.org/2013/08/27-ua-minutes.html#action05]

    <trackbot> Created ACTION-874 - Look at 2.5.1 location in
    hierarchy including possibly to check in with simon. [on Jan
    Richards - due 2013-09-03].

    Resolution: closed comment OCAD24, accepted.

OCAD22 re 2.3.5

    2.3.5 Customize Keyboard Commands: The user can override any
    keyboard shortcut including recognized author supplied
    shortcuts (e.g. accesskeys) and user agent user interface
    controls, except for conventional bindings for the operating
    environment (e.g. arrow keys for navigating within menus). The
    rebinding options must include single-key and key-plus-modifier
    keys if available in the...

    scribe: operating environment. The user must be able to save
    these settings beyond the current session. (Level AA)

    OCAD22: Save requirement should be removed as it is covered by
    2.7.1. Also the single-key and key-plus-modifier text seems
    like overkill.

    <AllanJ> jim's comment: proposal: eliminate last sentence it is
    covered by 2.7.1. remove the sentence related to
    key-plus-modifier. That is covered by overriding accesskey
    which is a key plus modifier.

    Greg: I don't think it's obvious to a developer that 2.7.1
    would cover this, but if we add to 2.7.1 a list of potentially
    overlooked implications such as this, then I'd be okay deleting
    this sentence.

    Kelly: Concern that if the user needs to be able to rebind the
    "D" key, it can make normal functionality unusable.

    Kim: Need to redo it, as if you're doing speech recognition and
    every key is interpreted as a long series of commands, it's a
    real problem.

    Jan: It doesn't say it has to allow rebinding of letter keys.

    Kelly: It doesn't say otherwise.

    <AllanJ> discussion of gmail and recognized keybindings....but
    gmail keybindings are all in javascipt and the browser is
    unaware of the keybindings.

    <AllanJ> scribe: allanj

    kp: there are more webapps using single key keybindings. these
    are a huge problem

    <greg> Kim: Increasing number of web apps use single letter
    keys as command, and that's a problem.

    <scribe> scribe: greg

    <scribe> scribe: allanj

    jim describes gmail (single keys turned on) and google chat
    conflicting.

    greg: modal commands that are context sensitive are a problem

    kp: single letter commands are becoming a nightmare

    srcibe: gret

    <scribe> scribe: greg

    Kim: Would be fine narrowing to being able to change shortcuts,
    but avoid requiring the user be able to rebind letter keys.

    Discussion of conflicts between webapp key commands and those
    of the user agent.

    Kim: In favor of being able to redefine keys that are used for
    commands, but not letters and so forth that aren't used for
    commands.

    Kelly: Kim wants the user to have control over whether keypress
    is handled by the UA or a script, but this doesn't really
    address that.

    <AllanJ> briefly discussed the previous SC related to the
    browser serving itself first (keybindings) before javascript.
    currently all browsers let javascript have the keybindings
    first then anything not trapped is passed to the browser.

    <AllanJ> this was removed as it was never going to be
    implemented.

    Jan: Browsers reserve some command keys, correct?

    Kelly: IE reserved Alt+D; cannot be used as accesskey.

    Jan: The UA always grabs the keys first, regardless of whether
    they're reserved or passed on to the script first.

    <AllanJ> proposal: 2.3.5 Customize Keyboard Commands: The user
    can override any keyboard shortcut including recognized author
    supplied shortcuts (e.g. accesskeys) and user agent user
    interface controls, except for conventional bindings for the
    operating environment (e.g. arrow keys for navigating within
    menus). The user must be able to save these settings beyond the
    current session. (Level AA)

    <AllanJ> perhaps remove the last sentence also, and add a
    statement about saving in the intent.

    <AllanJ> proposal: 2.3.5 Customize Keyboard Commands: The user
    can override any keyboard shortcut including recognized author
    supplied shortcuts (e.g. accesskeys) and user agent user
    interface controls, except for conventional bindings for the
    operating environment (e.g. arrow keys for navigating within
    menus). (Level AA)

    Kim, Jan and Greg agree on removing the Save from the SC and
    instead noting it in the IER.

    <AllanJ> add to the intent "the user should be able to save
    these settings beyond the current session"

    <Kim> The user should be able to save, import and export these
    settings.

    <AllanJ> add to related resources: GL 2.7

    <AllanJ> proposal proposal: 2.3.5 Customize Keyboard Commands:
    The user can remap any keyboard shortcut including recognized
    author supplied shortcuts (e.g. accesskeys) and user agent user
    interface controls, except for conventional bindings for the
    operating environment (e.g. arrow keys for navigating within
    menus). (Level AA)

    Greg: I don't like the idea that UA could allow remapping only
    to a very limited set of inputs, such as Ctrl plus a single
    letter (which is a real-world case), but I'm not going to fight
    about it.

    <AllanJ> opera allows remaping, firefox does with extension

    <AllanJ> opera only allows remaping of accesskeys, but not its
    own controls

    Jan: We may have difficulty finding implementations that let
    one remap *all* keyboard commands.

    Resolution: Accept wording 2.3.5 Customize Keyboard Commands:
    The user can remap any keyboard shortcut including recognized
    author supplied shortcuts (e.g. accesskeys) and user agent user
    interface controls, except for conventional bindings for the
    operating environment (e.g. arrow keys for navigating within
    menus). (Level AA)

OCAD16 re 2.1.4

    2.1.4 Separate Selection from Activation: The user can specify
    that focus and selection can be moved without causing further
    changes in focus, selection, or the state of controls, by
    either the user agent or author content. (Level A)

    OCAD16: Does "author content" need a definition? Sometimes also
    says "author supplied"

    <AllanJ> proposal: 2.1.4 Separate Selection from Activation:
    The user can specify that focus and selection can be moved
    without causing further changes in focus, selection, or the
    state of controls, by either the user agent or author supplied
    content. (Level A)

    Jim: That is, change "author content" to "author supplied
    content".

    Greg: "The user can resize viewports within restrictions
    imposed by the platform."
    ... "The user can resize viewports within restrictions imposed
    by the platform, overriding any values specified by the
    author."

    <Jan> 1.8.3 Resize Viewport: Users can maximize the size of
    top-level viewports up to the size of the display even if the
    author has specified a smaller size. (Level A)

    <Jan> 1.8.3 Resize Viewport: The user can resize viewports
    within restrictions imposed by the platform, overriding any
    values specified by the author. (Level A)

    Resolution: Accept wording 1.8.3 Resize Viewport: The user can
    resize viewports within restrictions imposed by the platform,
    overriding any values specified by the author. (Level A)

OCAD8 re 1.3.2

    Options: When highlighting classes specified by 1.3.1
    Highlighted Items, the user can specify highlighting options
    that include at least: (Level AA) (a) foreground colors, (b)
    background colors, and (c) borders (configurable color, style,
    and thickness)

    OCAD8: This seems like too much configurability, especially if
    the user agent developer has chosen highlighting styling to
    maximize visibility within the widest variety of possible
    content situations. Fluid UIOptions for example enlarges input
    fields and makes images underlined and bold.

    Resolution: Keep 1.3.2 as it is, because even though many UA
    developers may think they have chosen a good default
    highlighting option, there will be users who will require
    further customization.


Summary of Action Items

    [NEW] ACTION: Jan to look at 2.5.1 Location in Hierarchy
    including possibly to check in with Simon. [recorded in
    [29]http://www.w3.org/2013/08/27-ua-minutes.html#action05]
    [NEW] ACTION: Jeanne to add Betty example from Jim's email of
    27 August 2013 to 1.1.1 [recorded in
    [30]http://www.w3.org/2013/08/27-ua-minutes.html#action03]
    [NEW] ACTION: Jeanne to check capitalization of handle of 5.1.2
    and 5.1.3 [recorded in
    [31]http://www.w3.org/2013/08/27-ua-minutes.html#action01]
    [NEW] ACTION: jeanne to go through the guidelines and remove
    any period at the end of a guideline. [recorded in
    [32]http://www.w3.org/2013/08/27-ua-minutes.html#action04]
    [NEW] ACTION: jeanne to move examples from 2.11.8 to 1.1.1 and
    remove 2.11.8 [recorded in
    [33]http://www.w3.org/2013/08/27-ua-minutes.html#action02]

    [End of minutes]
      __________________________________________________________


     Minutes formatted by David Booth's [34]scribe.perl version
     1.138 ([35]CVS log)
     $Date: 2013-08-28 00:31:30 $
      __________________________________________________________

      [34] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
      [35] http://dev.w3.org/cvsweb/2002/scribe/

Scribe.perl diagnostic output

    [Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11
Check for newer version at [36]http://dev.w3.org/cvsweb/~checkout~/2002/
scribe/

      [36] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/OAD/OCAD/
Succeeded: s/CAD43/OCAD43/
Succeeded: s/examples in/examples for 3.4.1 in/
Succeeded: s/would/should/
Succeeded: s/emphaized/emphasized/
Succeeded: s/rendered/recognized/
Succeeded: s/LIke/Like/
Succeeded: s/Propose keep/Keep/
Succeeded: s/the SC/SC 2.9.2/
Succeeded: s/from/Remove from/
Found Scribe: kford
Inferring ScribeNick: kford
Found Scribe: JR
Found Scribe: Jan
Inferring ScribeNick: Jan
Found Scribe: greg
Inferring ScribeNick: greg
Found Scribe: allanj
Inferring ScribeNick: AllanJ
Found Scribe: greg
Found Scribe: allanj
Inferring ScribeNick: AllanJ
Found Scribe: greg
Inferring ScribeNick: greg
Scribes: kford, JR, Jan, greg, allanj
ScribeNicks: kford, Jan, greg, AllanJ

WARNING: No "Present: ... " found!
Possibly Present: Admin AllanJ GL Greg JA JR Jan Jeanne Jim KP Kelly Kim
  OCAD16 OCAD22 OCAD25 OCAD26 OCAD27 OCAD31 OCAD33 OCAD34 OCAD35 OCAD39 O
CAD43 OCAD45 Proposal example jeanne2 joined kford left srcibe trackbot
ua
You can indicate people for the Present list like this:
         <dbooth> Present: dbooth jonathan mary
         <dbooth> Present+ amy

Found Date: 27 Aug 2013
Guessing minutes URL: [37]http://www.w3.org/2013/08/27-ua-minutes.html
People with action items: jan jeanne

      [37] http://www.w3.org/2013/08/27-ua-minutes.html


    End of [38]scribe.perl diagnostic output]

      [38] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm


-- 
_______________________________
Jeanne Spellman
W3C Web Accessibility Initiative
jeanne@w3.org

Received on Wednesday, 28 August 2013 00:36:04 UTC