Mobile Accessibility Task Force Teleconference -- 30 Jun 2016

<Kathy> https://www.w3.org/WAI/GL/wiki/WCAG_2.1_timeline

Kathy: Deadline for 2.1. Coordination call with the other two taskforces
... crossover with low vision – affordances and contrast. Mobile drop these do not duplicate work – low vision take the lead on these and we will review
... timeline – proposal for 2.1 must be into WCAG working group by December 1. Format same as for touch and pointer – success criteria, understanding paragraph, one sentence of what the techniques would be. Techniques don't have to be written, just proposed
... goal for December one is to have that for any other success criteria we want to propose and any changes to touch and pointer
... keyboard proposal definition change back and forth in email. Answer from chairs as we can propose anything, doesn't mean it will go through. So will go ahead with that
... WCAG 2.1 2018 we are two years away from getting this officially out and launched
... if we don't have it in by December 1 will not get into WCAG 2.1, will have to wait until 3.0
... David on the mailing list success criteria we don't have in here – have to talk about where it fits in. Conforming with breakpoints, not enough to work on desktop, must work on mobile

Detlev: interaction with other task forces logistics?

Kathy: wiki page that the coordinators have access to – Task Force exchange

<jeanne> Issues in GH -> https://github.com/w3c/Mobile-A11y-Extension/issues

<Kathy> https://github.com/w3c/Mobile-A11y-Extension/issues/2

<Kathy> This is what the entire 75 email thread to the list has been about for me, summed up in one sentence. This is what I would like to see in WCAg 2.1 That is not in 2.0 and is not in any 2.1 workup documents I've seen in COGA, LVTF, or MATF.

<Kathy> https://github.com/w3c/Mobile-A11y-Extension/issues/2

<jon_avila> +1

<Kim_> Marc: move to 1.3 adaptable?

<davidmacdonald> sorry late

<jon_avila> 1.3

<Kim_> Kathy: did make this constrained. Wondering based on David's point if we need to revise this and talk about it in more general terms and have it move on different breakpoint and orientation

<jon_avila> WCAG allows alternatives under the conformance requirements

David: the whole crux of the problem to me – different breakpoints will shift different components even if it's the same content.

<jon_avila> You can also have a progressive enhancement site where minimal site is accessible but enhanced is not as long as you get to non-enhanced site

David: if I'm wrong, whole thread is necessary. Where in WCAG does it say two components to the same thing. You don't have to do anything as long as the link is accessible. I would say there's nothing in WCAG that says you have to have two components work if you have one component work and they do the same thing

<jon_avila> You can conform without making a conformance statement

David: under WCAG you can say our site is conforming – just go home and use your desktop just like you don't have to say it works in any one browser

Detev: very common error people design hamburger menus and assume they don't have to be keyboard accessible. I've always assumed that if you do provide specific layouts than all those WCAG success criteria also apply to that view

David: we have different interpretation of what WCAG is… my interpretation just one view one stack that conforms

<jon_avila> +1 to david

Kathy: in the US driven by a lot of legal requirements

David: I would love this to be wrong – I would love someone to prove me wrong because I don't want this to be true

Detlev: explicit requirements

<jeanne> 2. Full pages: Conformance (and conformance level) is for full Web page(s) only, and cannot be achieved if part of a Web page is excluded.

David: people just claim the minimum. Not very many people see this hole – want to see how I'm wrong

Jeanne: conformance requirement number 2

<jon_avila> You can meet with alternatives. +1 to david

David: I want that conformance requirement to block it in but I don't think it does. I think we have lots of precedent and language where it says you can find an alternate component that can meet your requirement if that requirement works.

<jeanne> There are notes that apply to LongDesc

<jeanne> Full pages: Conformance (and conformance level) is for full Web page(s) only, and cannot be achieved if part of a Web page is excluded.

<jeanne> Note 1: For the purpose of determining conformance, alternatives to part of a page's content are considered part of the page when the alternatives can be obtained directly from the page, e.g., a long description or an alternative presentation of a video.

<jeanne> Note 2: Authors of Web pages that cannot conform due to content outside of the author's control may consider a Statement of Partial Conformance.

<jon_avila> I disagree

Detlev: you could only claim that for Internet sites you could not claim that general-purpose websites accessible for jaws. I think conformance requirement 2 would cover including things that are shown only at particular breakpoints

David: John doesn't think so, I don't really think so. If that's true – I hope it is, I wanted to be. But maybe we should make it explicit. Six of the people who know WCAG best in disagreement about this. We need to be clear and make it explicit.

<jeanne> +1 to adding a note to Conformance #2

Kathy: we can make a proposal to add to conformance number 2

<jon_avila> +1 to david

David: every breakpoint – I think John, Patrick, Jason might answer no. I don't want to but I would answer no

<jon_avila> If doing to right it is the width of window not device

David: big thing is components that shift are different based on the size of your screen. Will change the layout of that one page, same content

<marcjohlic> https://www.w3.org/TR/WCAG20/#conforming-alternate-versiondef

<Detlev> +1 to Marc

Marc: when we do this make it accessible for mobile too, I think how they back that up is same functionality. Mobile get same exact thing that desktop gets that's fine but as soon as the developers try to make it work for mobile you're now targeting a mobile platform

<jon_avila> We agree with policy but WCAG doesn't clarify that.

David: conforming to alternative link – that was lots of conversation yesterday. If you shift page, link to bottom of page that says desktop site conforms you would meet WCAG
... link at the bottom of the page, takes 10 minutes to find that link, have to go through that terrible mobile menu that is not working…

Kathy: low-vision perspective as well – might want to coordinate about what they're thinking as far as breakpoints as well

<jon_avila> WCAG defintion: functionality processes and outcomes achievable through user action

<marcjohlic> https://www.w3.org/TR/WCAG20/#conforming-alternate-versiondef

David: one of their provisions is they want to be able to move it to one column. I would suggest ensure that all functionality in that view meets WCAG. There's nothing that I can see in the gap analysis that plugs that hole

Marc: you could extrapolate that you couldn't just tell someone go use the desktop version because then their process is completely different someone else's on that device.

<jon_avila> Example 1: Successful use of a series of Web pages on a shopping site requires users to view alternative products, prices and offers, select products, submit an order, provide shipping information and provide payment information.

Kathy: to complicate that further certain functions you provide different from mobile and desktop

<jeanne> A responsive site is not an alternative on another page, it is a single page with different display modes.

Jon: when I use 100% resolution I get multiple views on my desktop – when I zoom in I can't get to the other view and I have limited functionality and that's a problem for me on the desktop. We agree it's a problem, but I don't think it's addressed by the current WCAG
... we believe that if we put these new mobile requirements in we can address it in a success criteria for WCAG 2.1 without modifying

<jon_avila> we still can't hear you

<davidmacdonald> https://www.w3.org/WAI/GL/wiki/Components_delivered_as_part_of_the_initial_page_load_conform

Detlev: I agree with Jon. Good use cases for when you might want to see different things – people use mobile versions because they are simplified, much easier to do because they are different from the desktop sites. The whole idea that everything should be accessible in all versions is complicated by the fact that we won't be able to prescribe the same sets of functionality are offered. That...
... also relates to the distinction that Alistair made in the mailing list. Same URL, different sites These two things we need to separate out somehow

<davidmacdonald> This is what the entire 75 email thread to the list has been about for me, summed up in one sentence. This is what I would like to see in WCAg 2.1 That is not in 2.0 and is not in any 2.1 workup documents I've seen in COGA, LVTF, or MATF.

<davidmacdonald> [Jason] What you’re arguing for, then, is the following:

<davidmacdonald> If different user interface components or different versions of the content are provided, each customized for a distinct type of device or user agent, then the content only conforms to WCAG 2.1 if

<davidmacdonald> (1) Each of the different user interface components or versions of the content conforms to WCAG 2.1 or

<davidmacdonald> (2) A conforming alternate version is provided of each version of the content that does not conform, where the conforming alternate version is customized for the same type of device or user agent as the corresponding non-conformant version.

<jon_avila> Not sure on word customized

Kathy: #2 what he's saying as you need to have some sort of version that works on that particular user agent device. So if you had a desktop version wouldn't that still conform because you could just go to the desktop version even though your default is going to show the mobile version?

<jon_avila> What if the components can't be made accessible?

<jon_avila> on one platform

David: based on viewport size so very specific type of customization Very thin net. Each one of those components needs to meet WCAG

Jon: another concern – aria you menu keyword based won't work on iOS?

David: if you ship a menu your menu is now I custom version of that menu – might be different but shipped specifically for mobile device, that particular component that were shipped for mobile should work – that's what I'm saying

Jon: same functionality:

David: no. doesn't have to provide equivalent functionality of the desktop menu, but does have to conform to WCAG.
... a component that we shipped based on viewport size. So each one of those components that shipped at a different viewport size has to be compliant. It doesn't have to do the same thing as the other breakpoints, just has to meet WCAG

Jon: worry that it's overly broad. Might work for a menu, but other components…
... have to think about it more

Jeanne: Patrick said when we are talking about responsive design it's not an alternate page it's the same page.

David: but there's another component on this page which now is not showing that actually does work and if you just get yourself to a device that can show that then you've met WCAG

<jon_avila> for responsive -- but I'm thinking of non-responsive sites

Kathy: lots of pages these days that have things that you can't see that are still part of the page

Jeanne: but it's still a part of the page. Have to be careful about writing ourselves into a corner about a situation that is still in flux. More important related issue: people be able to choose which they get on their device

David: as long as we can ensure that. but we are three experts who have different opinions on this

<jon_avila> For responsive pages you have a strong case I agree. But david's desktop site example was not a responsive site example

Kathy: out of time – I have to think through this more in detail.

David: I think there's still lots of confusion.

Kathy: I'll talk to Andrew and Josh and see if we can get clarity as far as other opinions
... if we take it up in the working group call, more clarity as to what we should do in the task force

David: key question: three different breakpoints on your website does your menu have to meet WCAG get every breakpoint

Kathy: David to ask others as well
... good conversation – will get clarity and figure out direction

- DRAFT -

Mobile Accessibility Task Force Teleconference

30 Jun 2016

Attendees

Contents

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output