Mobile Accessibility Task Force Teleconference -- 27 Oct 2016

<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

- DRAFT -

Mobile Accessibility Task Force Teleconference

27 Oct 2016

Attendees

Contents

M13 Orientation

focus trap

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output