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