Minutes of teleconference of 27 June 2014

HTML minutes:
http://www.w3.org/2014/06/27-mobile-a11y-minutes.html

Text of Minutes:

    [1]W3C

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

                                - DRAFT -

              Mobile Accessibility Task Force Teleconference

27 Jun 2014

    See also: [2]IRC log

       [2] http://www.w3.org/2014/06/27-mobile-a11y-irc

Attendees

    Present
           Jeanne, Tim_Boland, kathyw, wuwei, JonA

    Regrets
           gavin, alan

    Chair
           KathyW

    Scribe
           jeanne

Contents

      * [3]Topics
          1. [4]Number 20 in Survey - support for physical keyboard
          2. [5]Different Screen Sizes, #21
          3. [6]Users can see what page they are on #22
          4. [7]Use Vertical Navigation #23
          5. [8]Links with the page contents to key pages #24
          6. [9]Provide Open/Closed state in information in menu
             icon #25
          7. [10]Menu can be zoomed to 200%
          8. [11]Links and actionalbe elements must be clearly
             distinguishable
          9. [12]Next meeting
      * [13]Summary of Action Items
      __________________________________________________________

    <trackbot> Date: 27 June 2014

    <kw> 1. /invite rrsagent

    <scribe> scribenick: jeanne

    <kathyw>
    [14]https://www.w3.org/2002/09/wbs/66524/20140512_survey/result
    s#xq21

      [14] https://www.w3.org/2002/09/wbs/66524/20140512_survey/results#xq21

Number 20 in Survey - support for physical keyboard

    KW: We have already talked about this issue and IndieUI

    JA: If IndieUI was supported, that would allow this to be met,
    but if you didn't use a device independent method, you would
    have to work with these versions.
    ... there would be other ways to meet it with the platform,
    like iOS Switch Access

    KW: Detlev was it was too hard to write test procedures for it.

    JS: Jan said it was a duplicate of #1

    Resolution: Duplicate

Different Screen Sizes, #21

    JA: It goes beyond WCAG, i think it should be a best practice

    KW: I'm not sure what we are solving

    JS: It is blocking responsive design, it could increase
    problems for people with low vision. I could see same
    navigation across orientation as a best practise for people who
    are targeting an audience with certain cognitive disabilities.

    KW: Where should we place it?

    JA: This is from the Funka Nu gap analysis.

    KW: 2.1.1 for keyboard

Users can see what page they are on #22

    KW: Comments from Jon and Detlev recommend it as sufficient
    technique under 2.4.8 AAA

    JS: Recommend tighting up the wording

    RESOLUTION: 22 as a Sufficient technique under SC 2.4.8 AAA and
    fix the wording when we work on it.

Use Vertical Navigation #23

    <jon_avila> *my audio is not working correctly. I am going to
    try to call in again.

    KW: Detlev said "should be more descriptive, I guess what is
    menat is "Provide vertical navigation mechanisms that work
    without horizontal scolling on narrow width screens )whih I
    admit may be too wordy)"

    JS: I don't think it should be ruled out, particularly for
    people working with fixed orientation portrait mode

    KW: I can't see anyone doing this because it would cause such a
    bad user experience. I don't think we should add something to
    the guidelines for unique cases.
    ... I recommend dropping it

    JS: +1

    <jon_avila> * I'm having trouble getting into the audio system
    now -- it says the passcode is invalid

    <kathyw> I just dropped

    <kathyw> calling back in

    RESOLUTION: drop #23

    <jon_avila> * passcode is 6283# right?

    <kathyw> yes

    botie, tell Kim we miss you

    <botie> jeanne: what?

    botie, inform Kim we hope you had a great vacation

    <botie> will do

    <botie> i already had it that way, jeanne.

Links with the page contents to key pages #24

    KW: jon remarked that it was already in 2.4.5
    ... are there any things that are different for mobile?
    ... can we say this is already covered under 2.4.5?

    RESOLUTION: Sufficient technique already covered under 2.4.5

Provide Open/Closed state in information in menu icon #25

    KW: This describes the "hamberger" menu icon to indicate
    whether or not a menu is open or if there is information
    available under it.

    JA: If it is ambiguous for everyone, it is not really an
    accessibility issue, except possibly for people with cognitive
    issues
    ... visually, what happens when the menu is closed, the icon is
    the same. If the menu is open, then the icon moves or has some
    visual indication
    ... would this be advisory or sufficient?

    KW: This would be a case where ArIA haspopup or ARIA expanded
    as a technique
    ... it's not necessarily apparent whether this should be
    apparent on a mobile device

    JA: I could support it as a sufficient, but not a failure
    ... we are talking about whether the user knows it is expanded
    or collapsed
    ... aria-expanded can only be used in [list]
    ... if people used valid markup, @@
    ... it would be ambiguous to users who can't see

    KW: Make a sufficient technique under 4.1.2

    TB: I think it should also go under 1.3.1

    KW: I think of 1.3.1 as semantic, but I can see it in both
    places

    RESOLUTION: #25 as a sufficient technique under 4.1.2 and 1.3.1
    ... #26 is a duplicate

Menu can be zoomed to 200%

    KW: It's already a technique under 1.4.4
    ... we can addresss Detlev's comment when we actually work on
    it.

    RESOLUTION: Sufficient technique under 1.4.4

Links and actionalbe elements must be clearly distinguishable

    Kw: [reads comments]

    RESOLUTION: Change wording of #13 to match #28 and consider
    them duplicates.

    <botie> jeanne: that doesn't look right

Next meeting

    No meeting 4 July

    Next meeting 11 July, we will start with #29

    trackbot, end meeting

Summary of Action Items

    [End of minutes]

Received on Friday, 27 June 2014 14:58:41 UTC