MATF Minutes 20 October 2016 from Kim Patch on 2016-10-27 (public-mobile-a11y-tf@w3.org from October 2016)

From: Kim Patch <kim@redstartsystems.com>
Date: Thu, 27 Oct 2016 12:09:15 -0400
To: "public-mobile-a11y-tf@w3.org" <public-mobile-a11y-tf@w3.org>
Message-ID: <581226AB.7040901@redstartsystems.com>
*MATF Minutes 20 October 2016 link: 
**https://www.w3.org/2016/10/27-mobile-a11y-minutes.html

Text of minutes:
*


  Mobile Accessibility Task Force Teleconference


    27 Oct 2016

See also: IRC log <http://www.w3.org/2016/10/27-mobile-a11y-irc>


    Attendees

Present
    Kathy, Jatin, jon_avila, Kim, chriscm, David, shadi
Regrets
    Patrick, Henny
Chair
    Kathy
Scribe
    Kim


    Contents

  * Topics <https://www.w3.org/2016/10/27-mobile-a11y-minutes.html#agenda>
     1. M13 Orientation
        <https://www.w3.org/2016/10/27-mobile-a11y-minutes.html#item01>
     2. focus trap
        <https://www.w3.org/2016/10/27-mobile-a11y-minutes.html#item02>
  * Summary of Action Items
    <https://www.w3.org/2016/10/27-mobile-a11y-minutes.html#ActionSummary>
  * Summary of Resolutions
    <https://www.w3.org/2016/10/27-mobile-a11y-minutes.html#ResolutionSummary>

------------------------------------------------------------------------

<Kathy> meeting: Mobile A11Y TF

trackbot, start meeting

<trackbot> Meeting: Mobile Accessibility Task Force Teleconference

<trackbot> Date: 27 October 2016

<Kathy> 
https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Proposed_SC_Orientation

Kathy: look at the success criteria that's been marked as reviewed by 
the task force in the spreadsheet on the wiki

<Kathy> 
https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/WCAG_2.1_Success_Criteria_Submission_Requirements

Kathy: timeline at the bottom – column that says reviewed by the task 
force. These are ones that are been reviewed and finalized and we will 
be sending out. Let me know this week if you have any changes – we are 
getting ready to submit these.

<David_> coming

Kathy: today we will focus on – and the next few meetings – we will 
focus on the rest of the success criteria we have identified. We have 
four key ones 13, orientation that Jonathan put together, focus trap, 
pointer inputs with additional sensors, and noninterference of AT

We're getting close. These are very specific to mobile and I want to 
make sure we get them all in well in advance of the deadline

<David_> forgot meeting PW

<Kathy> 
https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Proposed_SC_Orientation

Kathy: any questions about what has been done or the work that were 
going to be doing in the next couple weeks


      M13 Orientation

<David_> caps?

Jon: orientation wouldn't be locked except if it's necessary for content 
– exceptions may be a banking app where you have to rotate to take a 
picture of a check a certain way
... we discussed if there is an exception that be communicated to the 
user so they know why it's switching

<David_> I'm in

Kathy: should we put that note in the intent?
... alerting people that orientation is essential to content – making 
sure they have a warning

Jon: will edit intent to add this

Kathy: I don't know if we should do this or not – test procedure make 
sure content is available in both orientations. Where people might 
misinterpret is both orientations don't need to have the content in the 
same order. We might want to put in intent that portrait and landscape – 
the content doesn't have to be in the same order, it just needs to be 
logical. That's not part of this, but it...
... might be worth noting it here
... maybe just add as a note

David: although the content doesn't need to be in the same focus order 
and meaningful sequence for both orientations they do need to meet 2.4.3 
and 1.3.2

Chris: if were not going to send that they know that both orientations 
need to meet all criteria, just both orientations need to be WCAG 
compatible – accessible

must conform to WCAG criteria

Jon: and functionality

Shadi: keyboard sizes the change with orientation
... sometimes the keyboard is behind content

Jon: content needs to be available – but the keyboard needs to be taken 
as part of the test – that's a good reminder to add
... make sure content is not obscured by keyboard

Kathy: if we had a laptop that changes orientation but has a keyboard 
with it would be necessary to make sure the on screen keyboard
... specific to devices where there's not a standard physical keyboard 
attached

David: taking minutes at TPAC IRC was obscured by keyboard, couldn't use it

Kim: user might not use the keyboard even if it's attached

Kathy: do we need to have another success criteria that talks about that 
are with that just be assumed under 2.0– thinking through we are saying 
both orientations need to meet the guideline. Where would we convey that 
more than just in this one success criteria to let people know that this 
is actually a requirement
... I don't think it's necessarily known out there that you need to do that
... we're making the statement in here that both orientations need to 
meet the success criteria. You can't just make portrait accessible and 
not landscape. I think it's an important thing for people to realize 
just what is in this case a webpage – portrait and landscape

Jon: equivalent functionality needs to be available – not necessarily 
the same in both

Kathy: is it that intuitive for figuring out what the actual 
requirements are – not necessarily something everybody is thinking about

David: looking up proposed language on being accessible in every view

<David_> https://github.com/w3c/wcag/issues/197

David: this would plug that hole if anybody has been interpreting it 
that way. We shouldn't have to wait until 2.1 to fix this – or make it clear

Kathy: we need to include both landscape and portrait mode in there too

David: adding

<David_> "The full page includes each variation of the page that is 
automatically customized for various devices, browsers, orientation, or 
screen sizes. Each of these variations (or their respective conforming 
alternate versions) needs to conform in order for the entire page to 
conform. However, if a user actively chooses a setting on the page that 
optimizes or personalizes the state of the page for accessibility 
reasons, this new state does not necessarily nee[CUT]

<David_> Conformance Criteria 2

<jon_avila> Therefore, mobile applications need to support both 
orientations by making sure content and functionality is available in 
each orientation. While the order of content and method of functionality 
may have differences such as exposed behind a disclosure widget the 
content and functionality is available.

Jon: also update both content and functionality be available

Kathy: widget that expands or collapses or discloses information 
differently than another view
... do we need to define orientation?

John: right now we just have portrait and landscape in the future we 
could have potentially tilt – other axes that people could come up with

<David_> content is not locked to a specific orientation, except where 
orientation is essential for use of the content

Kathy: not necessarily locked to a specific orientation. In the 
definition, for example on mobile locked to portrait

Jon: if we move portrait and landscape out might not be as clear

Kathy: may have others in the future so we shouldn't lock it to portrait 
and landscape
... content is not locked to a specific orientation, e.g. landscape or 
portrait

David: I think that functionality is part of content

Jon: it's a very broad term, includes user interaction

David: we don't use functionality in many SCs, in 2.1.1 just to be clear
... 1.4.1 content or functionality – there is a certain on a distinction

Kathy: content not locked and all functionality works in all orientations

David: 2.1.3, 2.1.1 all functionality or content
... content and functionality are not locked to any specific orientation

Kathy: it's not the functionality being locked, just working
... what if functionality is available by mouse not by touch

Shadi: are these maybe two separate SCs – one under perceivable and one 
under operable?

<jon_avila> Content is not locked to a specific orientation and 
functionality is available across orientations, ...

David: I don't think so – I think they're really both about orientation

<David_> content is not locked to a specific orientation except where 
orientation is essential for use of the content, and functionality is 
not limited to a spcific orientation

<Kathy> Content is not locked to a specific orientation and the same 
functions are available in all orientations, except where orientation is 
essential for use of the content.

Going with Kathy's version

Kathy: all functionality of the content is operable in all orientations
... should we add another technique
... failure would be functionality is available in one orientation but 
not another

Chris: blank space – do we want developers to worry about that
... should the be a note made somewhere so that eventually that's 
required and not something application developers don't have to worry 
about – can we push both solutions

David: notes for silver?

Kathy: locking the orientation is one thing, functionality and content 
being the same as another
... any other changes?

*RESOLUTION: this is been reviewed by task force and is now ready for 
working group review*

<Kathy> https://github.com/w3c/Mobile-A11y-Extension/blob/gh-pages/SCs/m7.md


      focus trap

Kathy: Patrick's note – added to this but not sure it's needed
... Detlev shares the concern as well
... thoughts on this. I don't think I've come across a situation where 
this is a problem, but I wanted to see if someone else has a scenario 
that's not covered

David: several the success criterion's are largely theoretical. This is 
in that category

Kathy: Patrick's thought is to merge into 2.1.2

Jon: in theory somehow controlling the screen reader's order

Kathy: is there any situation whether we're talking about touch or 
pointer or anything with or without AT where we could have a focus trap 
that we need to solve
... is there a scenario where we actually need this?
... Jon the scenario you mentioned, is that an iOS bug?

Jon: yes. Another example. Carousel with hundreds of items or explore by 
touch to get out of it. There may be some way to jump past it that I can 
also envision a carousel that just keeps wrapping you around. More of a 
native app problem. I'm willing to drop it – other issues more important.

Kathy: for silver…

*RESOLUTION: drop M7 No Focus Trap for 2.1*

<Kathy> 
https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/WCAG_2.1_Success_Criteria_Submission_Requirements#Timeline

Kathy: timeline has the ones that are reviewed by the task force and 
current status and links to each of those. If anyone sees something 
that's missing or that you disagree with let me know – we have not yet 
submitted any of these. Will be submitted soon
... the ones that we haven't done yet – two outstanding M9 and M16
... Starting with M9 next week - feel free to email or bring up on next 
week's call anything on the ones that are finalized


    Summary of Action Items


    Summary of Resolutions

 1. this is been reviewed by task force and is now ready for working
    group review
    <https://www.w3.org/2016/10/27-mobile-a11y-minutes.html#resolution01>
 2. drop M7 No Focus Trap for 2.1
    <https://www.w3.org/2016/10/27-mobile-a11y-minutes.html#resolution02>

[End of minutes]
------------------------------------------------------------------------
Minutes formatted by David Booth's scribe.perl 
<http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm> 
version 1.148 (CVS log <http://dev.w3.org/cvsweb/2002/scribe/>)
$Date: 2016/10/27 16:05:48 $

___________________________________________________

Kimberly Patch
President
Redstart Systems
(617) 325-3966
kim@redstartsystems.com <mailto:kim@redstartsystems.com>

www.redstartsystems.com <http://www.redstartsystems.com>
- making speech fly

www.linkedin.com/in/kimpatch <http://www.linkedin.com/in/kimpatch>
___________________________________________________
Received on Thursday, 27 October 2016 16:10:04 UTC