MATF Minutes 30 June 2016 from Kim Patch on 2016-06-30 (public-mobile-a11y-tf@w3.org from June 2016)

From: Kim Patch <kim@redstartsystems.com>
Date: Thu, 30 Jun 2016 12:12:32 -0400
To: "public-mobile-a11y-tf@w3.org" <public-mobile-a11y-tf@w3.org>
Message-ID: <577544F0.4020801@redstartsystems.com>

*MATF Minutes 30 June 2016 link:
*https://www.w3.org/2016/06/30-mobile-a11y-minutes.html

*Text of minutes:*

- DRAFT -

Mobile Accessibility Task Force Teleconference

30 Jun 2016

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

Attendees

Present
jon_avila, Shadi, Kim, Detlev, jeanne, Marc, David, Kathy
Regrets
Patrick, Henny
Chair
Kathleen_Wahlbin
Scribe
Kim

Contents

* Topics <https://www.w3.org/2016/06/30-mobile-a11y-minutes.html#agenda>
* Summary of Action Items
<https://www.w3.org/2016/06/30-mobile-a11y-minutes.html#ActionSummary>
* Summary of Resolutions
<https://www.w3.org/2016/06/30-mobile-a11y-minutes.html#ResolutionSummary>

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

<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
<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
<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

Summary of Action Items

Summary of Resolutions

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

--
___________________________________________________

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

@RedstartSystems
www.linkedin.com/in/kimpatch <http://www.linkedin.com/in/kimpatch>
___________________________________________________

Received on Thursday, 30 June 2016 16:12:54 UTC