W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > October to December 2014

Minutes of UAWG F2F day 1 27 October 2014

From: Jeanne Spellman <jeanne@w3.org>
Date: Mon, 27 Oct 2014 20:29:37 -0400
Message-ID: <544EE371.3010403@w3.org>
To: UAWG <w3c-wai-ua@w3.org>
Minutes:
http://www.w3.org/2014/10/27-ua-minutes.html

Text of Minutes
    [1]W3C

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

                                - DRAFT -

     User Agent Accessibility Guidelines Working Group Teleconference

27 Oct 2014

    [2]Agenda

       [2] http://www.w3.org/WAI/UA/2014/F2Fagenda20141027

    See also: [3]IRC log

       [3] http://www.w3.org/2014/10/27-ua-irc

Attendees

    Present
           Kim, Jim, Jeanne, Jan, Kelly, Greg,
           Charles_LaPierre(Benetech)

    Regrets
    Chair
           Jim, Kelly

    Scribe
           allanj

Contents

      * [4]Topics
          1. [5]what's implemented
          2. [6]implementation testing
          3. [7]test 1.3.2
          4. [8]at risk element 1.2.1
          5. [9]at risk, 1.2.2
          6. [10]at risk 1.3.2
          7. [11]at risk 1.9.1 should just be headings
          8. [12]at risk 1.10.1 what do we test
          9. [13]at risk 2.2.2
      * [14]Summary of Action Items
      __________________________________________________________

    <trackbot> Date: 27 October 2014

    [15]http://jspellman.github.io/UAAG-LC-Comment/

      [15] http://jspellman.github.io/UAAG-LC-Comment/

    <jeanne> [16]http://www.w3.org/WAI/UA/2014/F2Fagenda20141027

      [16] http://www.w3.org/WAI/UA/2014/F2Fagenda20141027

    tests:
    [17]https://www.w3.org/WAI/UA/work/wiki/Tests_for_CR#Principle_
    1:_Perceivable

      [17] 
https://www.w3.org/WAI/UA/work/wiki/Tests_for_CR#Principle_1:_Perceivable

    <Greg> OK

    <kford>
    [18]http://en.wikipedia.org/wiki/Trident_(layout_engine)

      [18] http://en.wikipedia.org/wiki/Trident_(layout_engine)

    <scribe> scribe: allanj

    discussion of rendering engines vs UI

    chrome, opera = blink, firefox = gecko, IE = mshtml, safari =
    webkit

what's implemented

    desktop - V

    desktop -
    [19]http://w3c.github.io/UAAG-Implementations/desktop.html

      [19] http://w3c.github.io/UAAG-Implementations/desktop.html

    in browser column: Pass/Fail

    in the browser notes: if plugin/extension required (with url),

    include steps for settings or how to cause something to work

implementation testing

    browser assignments - Greg=Safari, Jan=Chrome, Jeanne=Firefox,
    Kelly=IE, Jim=Opera, Kim=mercury

    <clapierre> *Kelly, Charles LaPierre here I am observing,
    thought I would say Hi!*

    kim-mercury on the iPhone

    <Jan> [20]http://www.w3.org/WAI/demos/bad/before/survey.html

      [20] http://www.w3.org/WAI/demos/bad/before/survey.html

    <jeanne> Firefox, 1.3.1, Test 1, Pass

    <clapierre> FireFox 33.0.1 on Mac, Test 1, Pass

    <Jan> Chrome_Windows_v38, 1.3.1, Test 1, Pass

    opera v25 1.3.1 test 1 - pass

    gl: need to see that selection is different from focus

    jr: missing test

    kf: hightlighting definition does not include requirement for
    communication thru API.
    ... when screen readers used off-screen models we knew where SR
    got the information.

    this test has nothing to do with programmatic access, is it
    implicitly assumed that programmatic access is incuded

    gl: test procedure 3? doesn't seem right

    [21]http://www.w3.org/WAI/demos/bad/after/survey.html

      [21] http://www.w3.org/WAI/demos/bad/after/survey.html

    <Jan> [22]http://www.w3.org/WAI/

      [22] http://www.w3.org/WAI/

    <Jan> [23]http://www.w3.org/

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

    <Greg>
    [24]http://www.w3.org/WAI/AU/CR20/WCAG2_HTML_Problem_File_Fixed
    .html

      [24] http://www.w3.org/WAI/AU/CR20/WCAG2_HTML_Problem_File_Fixed.html

    <Jan> Chrome_Windows_v38, 1.3.1, Test 2, Pass

    <jeanne> Firefox 33, 1.3.1, Test 2, Pass

    <Jan> Chrome_Windows_v38, 1.3.1, Test 3, Pass (assuming that a
    flashing cursor is enough of a highlighting for text areas)

    <Greg> To test #3 you need to have both enabled and disabled
    elements. I used Safari's built-in debugger to add the
    "disabled" attribute to the INPUT element used for last name,
    then verified that it is rendered looking differently than the
    other INPUT, still enabled element.

    <Jan> Chrome_Windows_v38, 1.3.1, Test 4, Pass

    <Jan> Chrome_Windows_v38, 1.3.1, Test 5, Pass

    <Greg> However, the instructions for Test Procedure 3 are
    incorrect. This is not about which element is selected or has
    focus, but whether all the enabled elements can be
    distinguished at a glance from their disabled counterparts.

    <Jan> Chrome_Windows_v38, 1.3.1, Test 6, Pass

    <jeanne> Firefox 33, 1.3.1, Test 4, Pass

    IE_v11, 1.3.1, test 1, pass

    IE_v11, 1.3.1, test 2, pass

    IE_v11, 1.3.1, test 3, pass

    IE_v11, 1.3.1, test 4, pass

    IE_v11, 1.3.1, test 5, pass

    <Greg> The test document referenced should be referred to as
    "test page with rendered text and enabled *and disabled*
    elements".

    IE_v11, 1.3.1, test 6, pass (search term is highlighted white
    on blue, if you select something after searching, the search
    will change color to black on yellow, and selection is white on
    blue)

    <Greg> Ideally they would check each element type to verify
    that the enabled and disabled appearances are different.

    js: we need to have a place where we say "all of the test must
    pass"

    jr: edited

    <Jan>
    [25]http://www.w3.org/WAI/AU/CR20/WCAG2_HTML_Problem_File_Fixed
    .html

      [25] http://www.w3.org/WAI/AU/CR20/WCAG2_HTML_Problem_File_Fixed.html

    <jeanne> [26]https://www.w3.org/WAI/UA/work/wiki/1.3.1

      [26] https://www.w3.org/WAI/UA/work/wiki/1.3.1

    <k> safari ios8 on ipad test 1 pass

    <k> safari ios8 on ipad test 2 pass

    <k> mercury v8.7.2 1.3.1 test 1 pass

    <k> mercury v8.7.2 1.3.1 test 2 pass

    <Jan> Firefox 33, 1.3.1, Test 3, Pass (although the difference
    between enabled and disabled text entry areas is visually
    minimal)

    js: what is purpose of test 3, do we need it. what is the a11y
    case

    kp, and jr: it is needed to know what you can interact with
    before you get to it.

    <jeanne> Firefox 33, 1.3.1, Test 5, Pass

    <jeanne> Firefox 33, 1.3.1, Test 6, Pass

    <Greg> Safari 7.1, 1.3.1 passes all 6 tests (although the
    distinction between enabled and disabled elements is far too
    subtle)

    <Jan> Firefox 33, 1.3.1, 1-6 tests pass (Note: For Test 3 the
    difference between enabled and disabled text entry areas is
    visually minimal)

    IE_v11, 1.3.1, 1-6 pass, note6 (search term is highlighted
    white on blue, if you select something after searching, the
    search will change color to black on yellow, and selection is
    white on blue),

    <Jan> Chrome_Windows_v38, 1.3.1, passes 1-6 tests

    <k> safari ios8 on ipad test 1,2,4 pass, 5 fail (no find in
    page function), 3, 6 needed disabled element  not tested

    <k> mercury v8.7.2 1.3.1 test 1,2,4 pass, 5 fail (no find in
    page function), 3, 6 needed disabled element  not tested

    <jeanne> Tweet to a table of focusable elements in HTML ->
    [27]https://twitter.com/rodneyrehm/status/526655289643515904

      [27] https://twitter.com/rodneyrehm/status/526655289643515904

    <clapierre> FireFox 33.0.1 Mac 1-6 tests Pass

    [28]https://www.w3.org/WAI/UA/work/wiki/1.3.2

      [28] https://www.w3.org/WAI/UA/work/wiki/1.3.2

    <Jan>
    [29]http://www.w3.org/WAI/AU/CR20/WCAG2_HTML_Problem_File_Fixed
    .html

      [29] http://www.w3.org/WAI/AU/CR20/WCAG2_HTML_Problem_File_Fixed.html

    [30]http://lists.w3.org/Archives/Public/w3c-wai-ua/2014OctDec/a
    tt-0027/form2.htm

      [30] 
http://lists.w3.org/Archives/Public/w3c-wai-ua/2014OctDec/att-0027/form2.htm

    <jeanne>
    [31]http://www.w3.org/WAI/UA/CR-UAAG2/SampleFiles/TextElementsS
    amples.html

      [31] 
http://www.w3.org/WAI/UA/CR-UAAG2/SampleFiles/TextElementsSamples.html

    <k> Update mercury v8.7.2 1.3.1 test 1,2,4 pass, 5 pass with
    Search in Page extension; 3, 6 needed disabled element  not
    tested

test 1.3.2

    <Greg> In Test Procedure 1 it doesn't actually say to select
    any text or do other things that should highlight anything.

    <kford> If we have this question do our docks need to answer it
    better given we are asking it of ourselves?

    ja: what does 'size when the indicator is an image' mean/

    <k> note: puffin browser has a trackpad mouse

    gl: in google, the indicator of the current item in the search
    results was an image. the image would need to be resized. if
    not used mark as NA

    jr: user stylesheets are complicated, and most users wont use
    them. what is the requirement for the browser to allow changes
    to rendering of information.

    gl: Ideally the UA would provide a robust UI to do this, but
    not likely to happen.

    <Greg> In OS X Mavericks, you can choose between two and only
    two colors for highlighting keyboard focus: light blue, and
    gray. Safari does respect that choice, although it's of minimal
    value because it's so limited.

    <Greg> On the other hand, OS X Mavericks supports any highlight
    color for selected text (not just two choices).

    <Jan_> Firefox_for_Windows_v33 1.3.2 Test 1- Text selection
    PASS? - picks up OS selected item color (but can't change
    borders)

    <Jan> Firefox_for_Windows_v33 1.3.2 Test 2- Keyboard Focus
    PASS? - using Stylish add-on

    <Jan> Firefox_for_Windows_v33 1.3.2 Test 2- Keyboard Focus
    PASS? - using Stylish add-on (Native support removed)

    <k> Perfect Browser has a setting to enable 25 comment browser
    keyboard shortcuts for a Bluetooth keyboard: Settings/External
    keyboard shortcuts

    <clapierre> FireFox 33.0.1 Mac using Stylish add-on could Pass
    for test 2

    <Greg> Safari 7.1 on OS X Mavericks: 1.3.2: Test Procedure 1:
    Fail. (It respects the OS's preference for highlight background
    color, but does not allow changing foreground color
    automatically or manually, so some combinations are unreadable.
    No border support.)

    IE_v11_windows 1.3.2 Test 1, (internet options > general >
    colors > uncheck Windows Colors, then set whatever color for
    the 5 items. you can set background, IE takes care of
    contrasting foreground. NA on Foreground, Borders, Blinkrate

    IE_v11_windows 1.3.2 Test 2, menu: tools>accessibility>check
    'format documents using my style sheet', user must create style
    sheet, NA on size and blink rate

    <Greg> Safari 7.1 on OS X Mavericks: 1.3.2: Test Procedure 2:
    Fail. ( only allow changing the border color between light blue
    and light gray, and not the thickness, etc.)

    <Jan> Back from lunch...

    <Jan> [32]https://www.w3.org/WAI/UA/work/wiki/Tests_for_CR

      [32] https://www.w3.org/WAI/UA/work/wiki/Tests_for_CR

at risk element 1.2.1

    bullet 2: change to" If the user agent makes available metadata
    related to the non-text content available programmatically, but
    not via fields reserved for text alternatives" or

    eliminate it.

    Proposal: remove bullet 2 for 1.2.1. and rewrite 1.2.1

    <Jan> 1.2.1 Support Repair by Assistive Technologies: If text
    alternatives for non-text content are missing or empty, the
    user agent doesn't attempt to repair the text alternatives by
    substituting text values that are also available to assistive
    technologies (e.g. image file name).

    <Jan>
    [33]http://www.w3.org/TR/UAAG10/guidelines.html#tech-null-alt

      [33] http://www.w3.org/TR/UAAG10/guidelines.html#tech-null-alt

    <Greg> This is to avoid problems when (for example) the
    metadata in an image does not match the way it's being used on
    the current page. It allows a screen reader to distinguish
    between metadata provided by the page author, who knows the
    image's use here, vs. metadata tagging along from some long-ago
    source.

    <Greg> For example, John is creating a web page that uses an
    image of a check mark for "Selected". He grabs a PNG file from
    another site, not realizing that it's embedded IPTC TITLE
    attribute says "You are a winner!". John should set alt, but if
    he forgets to, it's better for a screen reader to say "image, I
    don't know what it means" than to say "image, You're a winner!"

    no browser does the above.

    any objections to new wording for 1.2.1

    none heard

    RESOLUTION: 1.2.1 Support Repair by Assistive Technologies: If
    text alternatives for non-text content are missing or empty,
    the user agent doesn't attempt to repair the text alternatives
    by substituting text values that are also available to
    assistive technologies (e.g. image file name). (AA)

at risk, 1.2.2

    <jeanne> ACTION: Jeanne to update the IER of 1.2.1 to reflect
    removing the metadata component. [recorded in
    [34]http://www.w3.org/2014/10/27-ua-minutes.html#action01]

    <trackbot> Created ACTION-1040 - Update the ier of 1.2.1 to
    reflect removing the metadata component. [on Jeanne F Spellman
    - due 2014-11-03].

    jr: you can only test to see if there is a UI component for
    turning on off feature. but what would the test file look like.
    how would we know if the UA did the right thing?

    recommend removing this SC

    RESOLUTION: mark @@ATRISK of removal, write Simon, can you come
    up with a test of expected behavior of the browser. separate
    from does the UI component exist.

at risk 1.3.2

    RESOLUTION: rewrite 1.3.2 break into separate items to make
    testing easier

    <scribe> ACTION: Jan to rewrite 1.3.2 to make testing easier
    [recorded in
    [35]http://www.w3.org/2014/10/27-ua-minutes.html#action02]

    <trackbot> Created ACTION-1041 - Rewrite 1.3.2 to make testing
    easier [on Jan Richards - due 2014-11-03].

    topic at risk 1.8.8

    should actually be 1.8.6

    "at the same location" is confusing

    gl: if the entirety of the point of regard is in the viewport
    when scaled, its ok. if larger than the viewport then some
    portion must remain in the viewport.

    <Greg> Note that the point of regard is NOT a point, but an
    element or range (e.g. button or selected text).

    <Jan> GL: When the point of regard is larger than the viewport,
    the user agent should emphasize the corner that is first
    according to the current language's reading order (e.g.
    Uppler-left corner for English)

    <Jan> 1.8.6 Maintain Point of Regard: The point of regard
    remains visible within the viewport when the viewport is
    resized, when content is zoomed or scaled, or when content
    formatting is changed. (Level A) Note: When the point of regard
    is larger than the viewport, the user agent should emphasize
    the corner that is first according to the current language's
    reading order (e.g. Uppler-left corner...

    <Jan> ...for English)

    <Jan> 1.8.6 Maintain Point of Regard: The point of regard
    remains visible within the viewport when the viewport is
    resized, when content is zoomed or scaled, or when content
    formatting is changed. (Level A) Note: When the point of regard
    is larger than the viewport, the user agent should keep visible
    the leading corner of the point of regard according to the
    current language's reading order (e.g....

    <Jan> ...Upper-left corner for English).

    <Jan> 1.8.6 Maintain Point of Regard: The point of regard
    remains visible within the viewport when the viewport is
    resized, when content is zoomed or scaled, or when content
    formatting is changed. (Level A) Note: When the point of regard
    is larger than the viewport, the user agent should keep visible
    the beginning of the point of regard according to the current
    language's reading order (e.g. first...

    <Jan> ...character or upper-left corner of an image in
    English).

    <Jan> 1.8.6 Maintain Point of Regard: The point of regard
    remains visible within the viewport when the viewport is
    resized, when content is zoomed or scaled, or when content
    formatting is changed. (Level A) Note: When the point of regard
    is larger than the viewport, the user agent keeps visible the
    beginning of the point of regard according to the current
    language's reading order (e.g. at least...

    <Jan> ...the first character in English).

    <Greg> For text, ideally have the entire range visible. If it's
    larger than the viewport, as much as possible of the text
    should be visible, including the beginning of the text
    according to its language's reading order.

    <Jan> 1.8.6 Maintain Point of Regard: The point of regard
    remains visible within the viewport when the viewport is
    resized, when content is zoomed or scaled, or when content
    formatting is changed. (Level A) Note: When the point of regard
    is larger than the viewport, the user agent keeps visible the
    beginning of the point of regard according to the current
    language's reading order (e.g. top-left in...

    <Jan> ...English).

    RESOLUTION: change 1.8.6 Maintain Point of Regard: The point of
    regard remains visible within the viewport when the viewport is
    resized, when content is zoomed or scaled, or when content
    formatting is changed. (Level A) Note: When the point of regard
    is larger than the viewport, the user agent keeps visible the
    beginning of the point of regard according to the current
    language's reading...
    ... order (e.g. top-left in English)

    <Greg> For text, ideally have the entire range visible. If it's
    larger than the viewport, as many characters as possible should
    be visible, including the first character according to its
    language's reading order. If the entire first character is
    larger than the viewport, the leading portion of the character
    should be visible (e.g. the upper left corner for English).

at risk 1.9.1 should just be headings

    <Jan> 1.9.1 Outline View: Users can view a navigable outline of
    the rendered content that allows focus to be moved to the
    corresponding element in the main viewport. (Level AA) Note:
    The elements reflected in the outline view depend on the web
    content technology, and may include headings, table captions,
    and content sections.

    <Jan> 1.9.1 Outline View: Users can view a navigable outline of
    named regions in the rendered content that allows focus to be
    moved to the corresponding region in the main viewport. (Level
    AA)

    <Greg> named regions (e.g. defined by headings, ARIA Landmark,
    or table captions)

    <Jan> Defn: Named Regions: ...

    <Greg> Named Regions: elements or ranges of content which the
    author has provided with a human-readable name.

    <Greg> Examples include regions defined by headings, ARIA
    landmarks, and table captions.

    <Jan> 1.9.1 Outline View: Users can view a navigable outline of
    the headings in the rendered content that allows focus to be
    moved to the corresponding element in the main viewport. (Level
    AA)

    <Greg> Named Regions: elements or ranges of content that have
    recognized, author-provided, human-readable names (i.e. names
    conveyed in attribute fields defined as being for human
    readers).

    <Jan> Note: An outline view might also include other named
    elements.

    <Jan> Note: An outline view might also include other named
    elements such as document landmarks.

    <clapierre>
    [36]http://www.w3.org/WAI/GL/wiki/Using_ARIA_landmarks_to_ident
    ify_regions_of_a_page

      [36] 
http://www.w3.org/WAI/GL/wiki/Using_ARIA_landmarks_to_identify_regions_of_a_page

    aria landmark roles
    [37]http://www.w3.org/TR/wai-aria/roles#landmark_roles

      [37] http://www.w3.org/TR/wai-aria/roles#landmark_roles

    <Jan> 1.9.1 Outline View: Users can view a navigable outline of
    the headings in the rendered content that allows focus to be
    moved to the corresponding element in the main viewport. (Level
    AA) Note: An outline view might also include other named
    elements such as document landmarks.

    RESOLUTION: change 1.9.1 Outline View: Users can view a
    navigable outline of the headings in the rendered content that
    allows focus to be moved to the corresponding element in the
    main viewport. (Level AA) Note: An outline view might also
    include other named elements such as document landmarks.

at risk 1.10.1 what do we test

    <Jan> 1.10.1 Show Related Elements: The user can access the
    information from explicitly-defined relationships in the
    content, including at least the following: (Level AA) - label
    for a control or image (e.g. HTML label element, figcaption or
    aria-labelledby attributes) - caption for a table - row and
    column labels for a table cell

    discussion, "control" is problematic

    jr: at least one type of label for each type of control or
    label.
    ... point of this was to make this information available to
    non-screen reader users.
    ... there are still many ways to label a control. could we use
    the 'accessible name' in the a11y api and reveal to user with a
    mechanism like right click on image in FF to get properties

    <Jan>
    [38]http://www.w3.org/TR/wai-aria/roles#textalternativecomputat
    ion

      [38] http://www.w3.org/TR/wai-aria/roles#textalternativecomputation

    <clapierre> There is the Firefox extension for navigating Aria
    Landmarks.
    [39]http://www.w3.org/TR/wai-aria/roles#landmark_roles The
    actual download of the extension is
    [40]https://github.com/matatk/landmarks/releases

      [39] http://www.w3.org/TR/wai-aria/roles#landmark_roles
      [40] https://github.com/matatk/landmarks/releases

    <Jan> 1.10.1 Show Related Elements: The user can access the
    information from explicitly-defined relationships in the
    content, including at least the following: (Level AA)

    <Jan> (a) calculated accessible name for images

    <Jan> (b) calculated accessible name for controls

    <Jan> (c) caption for a table

    <Jan> (d) row and column labels for a table cell

    <Jan> 1.10.1 Show Related Elements: The user can access the
    information from explicitly-defined relationships in the
    content, including at least the following: (Level AA)(a)
    calculated accessible name for images (b) calculated accessible
    name for controls (e.g. form fields, buttons) (c) captions for
    tables (d) row and column labels for table cells

    <Jan> 1.10.1 Show Related Elements: The user can access the
    information from explicitly-defined relationships in the
    content, including at least the following: (Level AA)(a)
    calculated accessible name for images (b) calculated accessible
    name for controls (e.g. form fields, buttons) (c) captions for
    tables (d) row and column labels for table cells [defn of using
    calculated accessible name [41]http://www.w

      [41] http://www.w/

    <Jan> 3.org/TR/wai-aria/roles#textalternativecomputation]

    <Jan> 1.10.1 Show Related Elements: Users can view the
    information from explicitly-defined relationships in the
    content, including at least the following: (Level AA)(a)
    calculated accessible name for images (b) calculated accessible
    name for controls (e.g. form fields, buttons) (c) captions for
    tables (d) row and column labels for table cells

    <Jan> 1.9.2 Source View:

    <Jan> The user can view all source text that is available to
    the user agent. (Level AAA)

    <Jan> 1.10.1 Show Related Elements: Users can view information
    from explicitly-defined relationships in the content, including
    at least the following: (Level AA)(a) calculated accessible
    name for images (b) calculated accessible name for controls
    (e.g. form fields, buttons) (c) captions for tables (d) row and
    column labels for table cells

    RESOLUTION: 1.10.1 Show Related Elements: Users can view
    information from explicitly-defined relationships in the
    content, including at least the following: (Level AA)(a)
    calculated accessible name for images (b) calculated accessible
    name for controls (e.g. form fields, buttons) (c) captions for
    tables (d) row and column labels for table cells

    change 1.10.1, now is testable

    <Jan> DEFN: calculated accessible name: The text equivalent
    computation is the name or description that they then publish
    through the accessibility API. {EXPLAIN why this is used}

    assumes that UA will provide a UI for 1.10.1

    <Jan> AllanJ, test

    back from break

    <scribe> ACTION: allanj to review duplicate items, make a
    proposal [recorded in
    [42]http://www.w3.org/2014/10/27-ua-minutes.html#action03]

    <trackbot> Error finding 'allanj'. You can review and register
    nicknames at <[43]http://www.w3.org/WAI/UA/tracker/users>.

      [43] http://www.w3.org/WAI/UA/tracker/users%3E.

    <scribe> ACTION: jallan to review duplicate items, make a
    proposal [recorded in
    [44]http://www.w3.org/2014/10/27-ua-minutes.html#action04]

    <trackbot> Created ACTION-1042 - Review duplicate items, make a
    proposal [on Jim Allan - due 2014-11-03].

at risk 2.2.2

    [45]http://pic.dhe.ibm.com/infocenter/cities/v1r5m0/index.jsp?t
    opic=%2Fcom.ibm.citieshelp.doc%2Fdoc_keyboard.html frame test
    page

      [45] 
http://pic.dhe.ibm.com/infocenter/cities/v1r5m0/index.jsp?topic=%2Fcom.ibm.citieshelp.doc%2Fdoc_keyboard.html

    <Jan>
    [46]http://www-archive.mozilla.org/docs/end-user/moz_shortcuts.
    html

      [46] http://www-archive.mozilla.org/docs/end-user/moz_shortcuts.html

    jr: what we really mean is sequential navigation between
    containers of controls (UAUI, nav areas, iframe, frame, main
    content area)
    ... is there something testable we can use, or make it only top
    level and only navigate from tab to tab

    <Jan> top-level viewport: A viewport that is not contained
    within another viewport of a platform-based user agent.
    Web-based user agents are always displayed inside another
    viewport, and therefore are never top-level viewports. A
    popular browser implementation is to provide a window that
    includes some UA user interface elements (e.g., menus) and a
    series of tabbed panels, each of which...

    <Jan> ...contains additional UA user interface elements (e.g.,
    address bar, bookmarks, back/forward buttons) and a top-level
    viewport for rendering a view of the addressed web resource.

    jr: get frame navigation. but we need to generalize. then how
    is browser to recognize the myriad ways to make a 'viewport"
    with or without scrollbars

    <Jan> JR: [[[A B C] D E F [G H I]]]

    <Jan> JR: Warping A D G

    <Jan> 2.2.1 Sequential Navigation Between Elements: The user
    can move the keyboard focus backwards and forwards through all
    recognized enabled elements in the rendered content of the
    current viewport. (Level A)

    <Jan> 2.2.2 Sequential Navigation Between Viewports: The user
    can move the keyboard focus backwards and forwards between
    viewports, without having to sequentially navigate all the
    elements in a viewport. (Level A)

    <Jan> 2.2.2 Sequential Navigation Between Element Groupings:
    The user can move the keyboard focus backwards and forwards
    between at least one type of element groupings in the current
    top-level viewport. (Level AA)

    <Jan> 2.2.2 Sequential Navigation Between Element Groupings:
    The user can move the keyboard focus backwards and forwards
    between the first recognized enabled elements in certain
    element groupings. (Level AA)

    <Jan> 2.2.2 Sequential Navigation By Landmarks: The user can
    move the keyboard focus backwards and forwards between a
    recognized enabled elements marked by landmarks. (Level AA)

    <Jan> 2.2.2 Sequential Navigation By Landmarks: The user can
    move the keyboard focus backwards and forwards between
    recognized enabled elements marked by landmarks. (Level AA)

    <Jan> 2.2.2 Sequential Navigation By Landmarks: The user can
    move the keyboard focus backwards and forwards between
    recognized enabled elements marked by document landmarks.
    (Level AA)

    gl: are landmarks the same as frames or iframes

    <Jan>
    [47]http://www.w3.org/TR/wai-aria/roles#document_structure_role
    s

      [47] http://www.w3.org/TR/wai-aria/roles#document_structure_roles

    <Jan> [48]http://www.w3.org/TR/wai-aria/roles#landmark_roles

      [48] http://www.w3.org/TR/wai-aria/roles#landmark_roles

    <Jan> 2.2.2 Sequential Navigation By Landmarks: The user can
    move the keyboard focus backwards and forwards between
    recognized enabled elements marked by document landmarks.
    (Level AA)

    <Jan> 2.2.2 Sequential Navigation By Landmarks: The user can
    move the keyboard focus backwards and forwards between
    recognized enabled elements in regions identified by document
    landmarks. (Level AA)

    <Jan> 2.2.2 Sequential Navigation By Landmarks: The user can
    move the keyboard focus backwards and forwards between
    recognized enabled elements to regions identified by document
    landmarks. (Level AA)

    kf: does this mean only aria landmarks. no browsers do this

    ja; there are extensions that do this.

    keyboard navigation between frames and iframes is broken across
    most browsers

    <Greg> [49]https://github.com/matatk/landmarks/releases

      [49] https://github.com/matatk/landmarks/releases

    <AllanJ> need to add an SC such that what the browser renders
    is accessible, form place holder text fails contrast test.

    Starting with completing 2.2.2 discussion tomorrow

    <AllanJ> need to add an SC such that what the browser renders
    is accessible, form place holder text fails contrast test.

Summary of Action Items

    [NEW] ACTION: allanj to review duplicate items, make a proposal
    [recorded in
    [50]http://www.w3.org/2014/10/27-ua-minutes.html#action03]
    [NEW] ACTION: jallan to review duplicate items, make a proposal
    [recorded in
    [51]http://www.w3.org/2014/10/27-ua-minutes.html#action04]
    [NEW] ACTION: Jan to rewrite 1.3.2 to make testing easier
    [recorded in
    [52]http://www.w3.org/2014/10/27-ua-minutes.html#action02]
    [NEW] ACTION: Jeanne to update the IER of 1.2.1 to reflect
    removing the metadata component. [recorded in
    [53]http://www.w3.org/2014/10/27-ua-minutes.html#action01]

    [End of minutes]
      __________________________________________________________
Received on Tuesday, 28 October 2014 00:29:57 UTC

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