IRC log of mobile-a11y on 2016-10-27

Timestamps are in UTC.

14:57:33 [RRSAgent]
RRSAgent has joined #mobile-a11y
14:57:33 [RRSAgent]
logging to http://www.w3.org/2016/10/27-mobile-a11y-irc
14:57:35 [trackbot]
RRSAgent, make logs public
14:57:35 [Zakim]
Zakim has joined #mobile-a11y
14:57:37 [trackbot]
Zakim, this will be WAI_MATF
14:57:37 [Zakim]
ok, trackbot
14:57:38 [trackbot]
Meeting: Mobile Accessibility Task Force Teleconference
14:57:38 [trackbot]
Date: 27 October 2016
14:57:43 [Kathy]
zakim, this will be 6283
14:57:43 [Zakim]
ok, Kathy
14:57:59 [Kathy]
meeting: Mobile A11Y TF
14:58:04 [Kathy]
rrsagent, make log world
14:58:12 [Kathy]
chair: Kathy
14:58:19 [Kathy]
present+ Kathy
14:59:52 [Kim]
Kim has joined #mobile-a11y
15:00:42 [Kim]
trackbot, start meeting
15:00:51 [trackbot]
RRSAgent, make logs public
15:00:53 [trackbot]
Zakim, this will be WAI_MATF
15:00:53 [Zakim]
ok, trackbot
15:00:53 [trackbot]
Meeting: Mobile Accessibility Task Force Teleconference
15:00:53 [trackbot]
Date: 27 October 2016
15:03:55 [Kathy]
https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Proposed_SC_Orientation
15:04:02 [Kim]
Agenda+ Continuation of SC review - https://github.com/w3c/Mobile-A11y-Extension/tree/gh-pages/SCs , https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/WCAG_2.1_Success_Criteria_Submission_Requirements M13 Orientation – https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Proposed_SC_Orientation
15:04:03 [Kim]
Agenda+ M7 No Focus Trap - https://github.com/w3c/Mobile-A11y-Extension/blob/gh-pages/SCs/m7.md
15:04:05 [Kim]
Agenda+ Next steps and schedule
15:04:16 [Jatin]
Jatin has joined #mobile-a11y
15:04:16 [chriscm]
chriscm has joined #mobile-a11y
15:04:31 [Jatin]
present +Jatin
15:04:40 [Kim]
Kathy: look at the success criteria that's been marked as reviewed by the task force in the spreadsheet on the wiki
15:04:41 [Kathy]
https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/WCAG_2.1_Success_Criteria_Submission_Requirements
15:05:24 [Kim]
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.
15:05:50 [jon_avila]
jon_avila has joined #mobile-a11y
15:06:09 [David_]
David_ has joined #mobile-a11y
15:06:12 [jon_avila]
present+jon_avila
15:06:14 [David_]
coming
15:06:15 [Kim]
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
15:06:35 [Kim]
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
15:06:40 [David_]
forgot meeting PW
15:06:48 [Kim]
Present+ Kim
15:06:56 [Kathy]
https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Proposed_SC_Orientation
15:06:59 [Kim]
Kathy: any questions about what has been done or the work that were going to be doing in the next couple weeks
15:07:23 [Kim]
TOPIC: M13 Orientation
15:07:25 [David_]
caps?
15:08:32 [Kim]
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
15:09:19 [Kim]
Jon: we discussed if there is an exception that be communicated to the user so they know why it's switching
15:09:24 [David_]
I'm in
15:09:26 [Kim]
Kathy: should we put that note in the intent?
15:09:41 [Kim]
Kathy: alerting people that orientation is essential to content – making sure they have a warning
15:10:30 [Kim]
Jon: will edit intent to add this
15:12:05 [Kim]
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...
15:12:06 [Kim]
...might be worth noting it here
15:12:45 [Kim]
Kathy: maybe just add as a note
15:14:03 [Kim]
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
15:15:11 [Kim]
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
15:16:02 [Kim]
must conform to WCAG criteria
15:16:21 [Kim]
Jon: and functionality
15:17:02 [Kim]
Shadi: keyboard sizes the change with orientation
15:17:17 [Kim]
Shadi: sometimes the keyboard is behind content
15:17:46 [Kim]
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
15:18:23 [Kim]
Jon: make sure content is not obscured by keyboard
15:18:43 [Kim]
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
15:19:11 [Kim]
Kathy: specific to devices where there's not a standard physical keyboard attached
15:19:33 [Kim]
David: taking minutes at TPAC IRC was obscured by keyboard, couldn't use it
15:20:26 [Kim]
Kim: user might not use the keyboard even if it's attached
15:21:38 [Kim]
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
15:21:52 [Kim]
Kathy: I don't think it's necessarily known out there that you need to do that
15:23:20 [Kim]
Kathy: 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
15:23:37 [Kim]
Jon: equivalent functionality needs to be available – not necessarily the same in both
15:24:08 [Kim]
Kathy: is it that intuitive for figuring out what the actual requirements are – not necessarily something everybody is thinking about
15:24:58 [Kim]
David: looking up proposed language on being accessible in every view
15:25:13 [David_]
https://github.com/w3c/wcag/issues/197
15:26:21 [Kim]
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
15:26:41 [Kim]
Kathy: we need to include both landscape and portrait mode in there too
15:26:48 [Kim]
David: adding
15:27:09 [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]
15:27:33 [David_]
Conformance Criteria 2
15:27:38 [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.
15:28:16 [Kim]
Jon: also update both content and functionality be available
15:28:59 [Kim]
Kathy: widget that expands or collapses or discloses information differently than another view
15:31:04 [Kim]
Kathy: do we need to define orientation?
15:31:47 [Kim]
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
15:32:22 [David_]
content is not locked to a specific orientation, except where orientation is essential for use of the content
15:32:27 [Kim]
Kathy: not necessarily locked to a specific orientation. In the definition, for example on mobile locked to portrait
15:32:43 [Kim]
Jon: if we move portrait and landscape out might not be as clear
15:32:52 [Kim]
Kathy: may have others in the future so we shouldn't lock it to portrait and landscape
15:33:08 [Kim]
Kathy: content is not locked to a specific orientation, e.g. landscape or portrait
15:35:15 [Kim]
David: I think that functionality is part of content
15:35:41 [Kim]
Jon: it's a very broad term, includes user interaction
15:35:59 [Kim]
David: we don't use functionality in many SCs, in 2.1.1 just to be clear
15:36:50 [Kim]
David: 1.4.1 content or functionality – there is a certain on a distinction
15:37:04 [Kim]
Kathy: content not locked and all functionality works in all orientations
15:37:21 [Kim]
David: 2.1.3, 2.1.1 all functionality or content
15:39:01 [Kim]
David: content and functionality are not locked to any specific orientation
15:39:15 [Kim]
Kathy: it's not the functionality being locked, just working
15:40:55 [Kim]
Kathy: what if functionality is available by mouse not by touch
15:41:28 [Kim]
Shadi: are these maybe two separate SCs – one under perceivable and one under operable?
15:41:45 [jon_avila]
Content is not locked to a specific orientation and functionality is available across orientations, ...
15:41:51 [Kim]
David: I don't think so – I think they're really both about orientation
15:41:51 [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
15:42:17 [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.
15:42:59 [Kim]
Going with Kathy's version
15:43:49 [Kim]
Kathy: all functionality of the content is operable in all orientations
15:45:59 [Kim]
Kathy: should we add another technique
15:46:24 [Kim]
Kathy: failure would be functionality is available in one orientation but not another
15:46:51 [Kim]
Chris: blank space – do we want developers to worry about that
15:47:19 [Kim]
Chris: 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
15:47:26 [Kim]
David: notes for silver?
15:48:08 [Kim]
Kathy: locking the orientation is one thing, functionality and content being the same as another
15:50:31 [Kim]
Kathy: any other changes?
15:50:44 [Kim]
RESOLUTION: this is been reviewed by task force and is now ready for working group review
15:50:53 [Kathy]
https://github.com/w3c/Mobile-A11y-Extension/blob/gh-pages/SCs/m7.md
15:50:58 [Kim]
TOPIC: focus trap
15:51:12 [Kim]
Kathy: Patrick's note – added to this but not sure it's needed
15:51:25 [Kim]
Kathy: Detlev shares the concern as well
15:51:50 [Kim]
Kathy: 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
15:52:20 [Kim]
David: several the success criterion's are largely theoretical. This is in that category
15:52:30 [Kim]
Kathy: Patrick's thought is to merge into 2.1.2
15:55:25 [Kim]
Jon: in theory somehow controlling the screen reader's order
15:56:06 [Kim]
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
15:56:19 [Kim]
Kathy: is there a scenario where we actually need this?
15:57:30 [Kim]
Kathy: Jon the scenario you mentioned, is that an iOS bug?
15:58:33 [Kim]
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.
15:58:46 [Kim]
Kathy: for silver…
15:59:59 [Kim]
RESOLUTION: drop M7 No Focus Trap for 2.1
16:00:30 [Kathy]
https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/WCAG_2.1_Success_Criteria_Submission_Requirements#Timeline
16:01:03 [Kim]
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
16:01:41 [Kim]
Kathy: the ones that we haven't done yet – two outstanding M9 and M16
16:02:16 [chriscm]
present+ chriscm
16:02:17 [Kim]
Kathy: Starting with M9 next week - feel free to email or bring up on next week's call anything on the ones that are finalized
16:03:00 [Kim]
rrsagent, make minutes
16:03:00 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/10/27-mobile-a11y-minutes.html Kim
16:03:59 [Kim]
Present+ David, shadi
16:05:32 [Kim]
Regrets+ Patrick, Henny
16:05:43 [Kim]
rrsagent, make minutes
16:05:43 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/10/27-mobile-a11y-minutes.html Kim
16:09:55 [Kim]
rrsagent, bye
16:09:55 [RRSAgent]
I see no action items