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

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Default Present: KimPatch, JakeAbma, Kathy, shadi, MarcJohlic, Detlev, Chris
Present: KimPatch JakeAbma Kathy shadi MarcJohlic Detlev Chris
No ScribeNick specified.  Guessing ScribeNick: KimPatch
Inferring Scribes: KimPatch
Found Date: 07 Feb 2019
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)