MATF Minutes 7 February 2019

*MATF Minutes 7 February 2019 link: * 
*https://www.w3.org/2019/02/07-mobile-a11y-minutes.html

*


  Mobile Accessibility Task Force Teleconference


    07 Feb 2019


    Attendees

Present
    KimPatch, JakeAbma, Kathy, shadi, MarcJohlic, Detlev, Chris
Regrets

Chair
    Kathleen_Wahlbin
Scribe
    KimPatch


    Contents

  * Topics <https://www.w3.org/2019/02/07-mobile-a11y-minutes.html#agenda>
     1. minimum spacing
        <https://www.w3.org/2019/02/07-mobile-a11y-minutes.html#item01>
     2. Landscape and portrait mode
        <https://www.w3.org/2019/02/07-mobile-a11y-minutes.html#item02>
  * Summary of Action Items
    <https://www.w3.org/2019/02/07-mobile-a11y-minutes.html#ActionSummary>
  * Summary of Resolutions
    <https://www.w3.org/2019/02/07-mobile-a11y-minutes.html#ResolutionSummary>


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

https://docs.google.com/spreadsheets/d/1wRAViPfAJ4Ytqc71tGZp6gU07HNd2QQaNgtJsog-D90/edit?usp=sharing

Working process: https://www.w3.org/WAI/GL/wiki/WCAG_2.2_working_process 
SC acceptance criteria: 
https://www.w3.org/WAI/GL/wiki/WCAG_2.2_Success_criteria_acceptance_requirements

https://docs.google.com/document/d/1MWdfQN3IhYx7sPexyGbgtHAYWY3HAJiYwVyrjw_MfCE/edit?usp=sharing

Kim – template

Kathy: looking at success criteria for 2.2, go through Google Docs 
spreadsheet to see levels and finalize if this is going to be a 2.2


      minimum spacing

Kathy: level – I put in my initial thoughts but I wanted to have a 
discussion. I have it at AA o right now

Chris: AA just because there's some potential for breaking this – I 
think AA is good

Detlev: exception for unstyled

Kathy: there's nothing natively in HTML that controls the spacing 
between the elements all you have is the actual size of the control
... typically people put non-breaking space between controls – how much 
pixels or between the nonbreaking space – anybody know?

Chris: it's at the very least defined by the font

Detlev: content which is semantically marked up – there's a row of 
buttons. It sits there there's no separation between them. It's probably 
rare because visually it would look odd.

Kathy: found its point 4 EMs, so if you don't style anything that's 
eight pixels with a nonbreaking space
... if you do absolutely no styling is going to default to the browser 
font which is .4 EMs
... it seems like if we say set 8 CSS pixels we might have enough, that 
would involve a nonbreaking space between elements

Detlev: where there is unstyled content there may not be a nonbreaking 
space. Might get pushback. We could do an exception for unstyled native 
stuff if that comes up

Kathy: it's just adding a space between elements

Jake: are we just talking about a new breaking space between links for 
example. Three, maybe four pixels with a nonbreaking space between it
... nonbreaking space in between two buttons

Kathy: maybe we need to research more

Detlev: if there was such an exception it wouldn't do much harm because 
it wouldn't be applicable to very much competent

Kathy: if we going to end up having the same list of exceptions as 
target size I see very little value in pushing this through. If we have 
all the same exceptions as target size why not just you target size?

Detlev: this accounts for the many cases where people want to use 
smaller controls. Example sorting arrows and tables, pixels are much 
smaller normally than 44 x 44. People want to continue to use them 
without taking up a lot of space so you can easily create enough 
distance between those controls to make sure that you can hit them.

Chris: if there's distance between those controls and there's a div 
that's creating that difference. The image doesn't have to be the thing 
that's clickable. So the catch points were not accomplishing anything.

Detlev: but you would prevent people putting tiny controls close to each 
other like in toolbars

Chris: but if you have to have a minimum size you can't do that

Detlev: toolbar with controls, row of icons, you would just need to make 
sure that the distance between icons keeps that minimum distance but you 
can still keep it a very narrow strip of controls, for example. You 
would need the full 44 x 44. So that could accomplish what a designer 
wants – I don't think it's the same as putting a div around it

Kathy: if we going to do that we might as well put all four exceptions 
in their the same as target size

Detlev: I don't think it will cause much harm to do that. Well, radio 
buttons will be the most frequent case where you have tiny things

Jake: we still want spacing no matter how the size is determined
... also another advantage – when we talk about touch targets, problem 
with list of links. Now if links are just defaults at least four pixels 
between them so they are better usable on smaller devices. That's 
another plus
... I also mentioned last time when we have the eight pixel distance 
between touch targets as AA we also promote automatically to make, for 
instance navigation targets at least 44 because most of the time you 
don't want a pixels between.so you would choose 44 x 44

Detlev: why would it not be relevant

Jake: if a control is left at 44 x 44 then we don't care about controls 
which are less because they automatically if you leave them default you 
need to add a pixels between them

Detlev: 44 x 44 is AAA Criteria

Jake: if size is not the problem but we need spacing isn't that what we 
want. Doesn't matter if you make your own button or if you use a default 
button

Detlev: I think that requirement is sensible and could apply to native 
controls just as well

Jake: if you don't style your native controls and even if they are not 
44 x 44 then at least make sure there is space between. That's not the 
same as touch target where if you don't we don't like it, but it's the 
exception
... if we don't do that and say the spacing of the target is determined 
by the user agent – does it have to be size and spacing is it always a 
combination
... example List and links between them

Detlev: most likely cases footnote numbers at the end of a sentence they 
often get very close. That would be covered by the in-line exception
... so the user agent control one could be taken out maybe

Kathy: I didn't want it in there – I'm fine to be overruled to say that 
it's not very likely. I also think that spacing when you don't have 
anything styled is going to be eight pixels. That may not come up

Detlev: I think we can probably take out the user engine control 
exception. Because we are basically mandating make sure there is some 
space between things if you have a list of links. It couldn't be unstyled
... that could mean that if you have a list of links you'd have to apply 
style to create that space
... unordered list of links, don't style it than that would be less than 
eight pixels distance between them. So we are mandating CSS

Jake: yes, that's the way to create that distance
... go back to touch targets – it doesn't matter if the user agent or 
not, if they are too small we want more space between them
... if default targets not enough that's the core cause of why we even 
talk about this

Detlev: if we want to have the possibility to keep unstyled text, say 
unordered list of links and text somewhere that should be fine because 
users can then zoom in and create the target size by zooming in, for 
example. That could be an argument
... argument about unstyled controls or native exception somehow
... I think we could leave it the way it is right now and if that comes 
up in discussions and we get this additional requirement it won't do 
much harm because it's fairly rare anyway

Kathy: we can go with it like this and take the feedback and change it 
if needed
... is everybody good with level AA

Jake: something else – measuring the distance and it is eight when I 
remove everything and just use the default blank page
... with the default 16 font size

General agreement as AA

Kathy: we can put this in the SC template and fill in the rest of the 
details on that


      Landscape and portrait mode

Kathy: I suggested a single-A level for this
... also do you think we should change the wording
... my concern with this is if you have something in portrait mode you 
have a smaller size so that functionality may be available on the site. 
It might not be available on that page itself. You might have a separate 
page to do that function and were not being clear as to what it actually 
means to be available
... does that mean we should change the success criteria or if it's fine 
we can just clarify that in understanding. But that's BUS for me and 
that one
... But that's ambiguous for me on that one

Detlev: do we really need an additional success criteria beyond 
orientation and reflow

Jake: we do cover reflow but in this case it was not about re-flowing. 
Just totally different content is shown in landscape and portrait. 
That's not covered.
... I've seen it many times
... stock with a lot of options to show what stock does – options are 
only available in landscape mode. A lot of the options not possible 
without landscape view. A lot of websites like that – they add 
functionality when in landscape because there's more space

Detlev: if you have a narrow portrait view it's not easy fit the stuff 
in. Maybe a chart with overlays. Cases where it's difficult or 
impossible to build the same kind of information into the display. You 
may find it further down but then the link gets lost. Maybe something 
hovering over a particular bit of the graph
... we might be pushing things too far to say both have to be 
equivalent. But maybe we should try its laudable but I don't think it 
will be easy in all situations

Jake: if you have another page to do that information is not a problem. 
It's only a problem if it's just not available for people
... when your iPad is mounted on your wheelchair in portrait mode

Detlev: I totally get the point and think it's a good criteria I just 
anticipate there will be a lot of pushback. That doesn't mean we 
shouldn't try

Kathy: can we actually test this. Do we know what the width of portrait 
and landscape motives? I can change my desktop in the landscape and 
portrait mode, my phone, my tablet. There are varying different widths 
and heights. Is this something that we could actually test?
... if we put out something that says all functionality must be 
available in both landscape and portrait mode. Or we rewrite it and say 
information has to be presented without loss of functionality in 
landscape or portrait mode, what do we define as landscape or portrait mode

Detlev: we have a fixed measure already in reflow. If anything it would 
be a requirement that if the viewport is 320 the information would still 
be there.

Kathy: in reflow we say content can be presented without loss of 
information or functionality

Jake: landscape or portrait is just fixed according to the operating 
system where you say this is landscape or portrait.

Detlev: triggered on a big screen?

Kathy: you have different widths of your screen. In portrait mode your 
browser with changes if you have it maximized to the window
... for responsive and almost seems like this would already be covered 
under 1.4.10 reflow. Where I see the gaps right now between landscape 
and portrait mode is where we have an adaptive layout not a responsive 
layout. So if we have an adaptive layout where we are looking at the 
screen width there might be differences.
... the reflow one is geared toward more responsive layouts

Jake: example responsive version where both layouts all functionality – 
shows it's a choice

Detlev: for example rivals on airport website. On your mobile you get a 
simplified list of arrivals. Usability advantages of not cluttering the 
screen with other things. Would you meet this requirement when you then 
have on the bottom of the screen abutting go to desktop version and you 
get a non-reflowable kind of desktop version?

Jake: I'm wondering if we can come up with examples where you can just 
not apply the same kind of functionality

Detlev: if you want to have links to everything that you might have on 
the desktop version where you see the arrivals, navigation, other stuff 
you would need to put controls on a screen that would mean you would 
take screen real estate so it becomes less usable for that targeted 
purpose of just saying when you're planes going to land. There are 
arguments in the usability community – the benefits of having 
alternative versions for different types [CUT]
... and screenreader states

Jake: going back to people who are not able to turn the devices are not 
able to use functionalities. Stock applications or it is almost 
essential when you use that product more intensely than just buying 
something and looking at where it is at. If you're buying, selling 
looking at five minutes ago, 10 minutes ago, options. People are 
excluded from using a lot of applications. There lots of websites out 
there that do not provide the same kind of fun[CUT]
... not using reflow, but just showing a completely different 
functionality. Two different pages, two different views.

Detlev: in my view you would be able to meet that success criteria if 
you had the link to a desktop version. Having said that the desktop 
version if it's going to be a a conforming alternative, so it would have 
to reflow on that narrow viewport.
... but at least you would get the full version which has all the 
options that you have on the desktop version
... we're not talking about native, the situation would be different for 
native. There many applications where you can't change orientation and 
then get another view. It's just fixed on the phone you just have the 
portrait review and that's it

Jake: why don't we do an agnostic version – same for native and web

Detlev: in my experience you're talking about 90% of native applications 
which don't change when you change orientations so you're up against a 
brick wall. For native I think this won't work for the moment

Kathy: if you look at the WCAG to ICT documentation you could say that 
applies to mobile app. But written for web, and doing the same thing for 
2.2.
... I don't see where there's really a difference but we are focused on 
web content.
... I put two options in the Google doc for this success criteria if we 
feel we want to keep it in
... preferences?
... the first one is worded more like WCAG 2.1 standards, content on the 
page, versus all functionality – just a different way of presenting

Jake: the second one sounds more like plain language
... otherwise equal in wording

Detlev: do we have landscape and portrait in the glossary right now?
... I think the argument will be on the desktop it doesn't trigger 
reorienting
... Airport example, it would probably look at the viewport rather than 
checking whether it's CSS orientation is landscape or portrait but I'm 
not sure – would be worth finding out

Kathy: display orientation such as portrait or landscape – we probably 
want to stick with the same terminology
... the orientation one got in at AA

Detlev: we can look at examples were there is a reduced view and narrow 
viewport – what is it triggered by

Kathy: in both of those examples if we magnify to 400%, that's where 
were still seeing the issue with portrait and landscape mode?
... so those two scenarios are not covered by reflow?
... in those scenarios if we satisfied reflow would we still have a 
problem going to portrait/landscape

Jake: completely different pages, and not that there was reflow without 
some functionality lost – just two different designs to different 
functionalities
... that is why we came up with this does not fit in reflow. It's also 
for PDFs

Detlev: checking two airport sites – no difference turning phone. Not 
sure if it's different on desktop. We need to collect some examples and 
find some cases where that is independent of reflow

Kathy: which level

Jake: it feels like it should be A, but maybe when you consider the work 
needed, maybe AA would be a better fit. But if you are preventing people 
from using core functionality I would say A. Maybe we can start with Alpha.

Kathy: do we want this to say content and functionality?

Jake yes

Kim +1

Kathy: Jake, if you can find some examples that would be good – we need 
to see what is covered under reflow


    Summary of Action Items


    Summary of Resolutions

[End of minutes]
------------------------------------------------------------------------
Minutes manually created (not a transcript), formatted by David Booth's 
scribe.perl 
<http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm> version 
1.154 (CVS log <http://dev.w3.org/cvsweb/2002/scribe/>)
$Date: 2019/02/07 17:50:27 $

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



___________________________________________________

Kimberly Patch

www.redstartsystems.com <http://www.redstartsystems.com>
- making speech fly

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