<jon_avila> I can't get into the webex. Is anyone else having that issue?

<Kathy> scribe: Kathy

Issue 850 (https://github.com/w3c/wcag21/issues/850)

Andrew - started talking about this

scribe: may have a decent path forward

<AWK> https://github.com/w3c/wcag21/issues/850

Alastair - how much are things cumulative, added a note in the conformance statement

scribe: need to test all breakpoints
... all SCs apply
... Jon noted that there are contrast issues that come up with the screen resize
... next actions is to clarify in the understanding documents

Chuck - how I am interpreting this is that we would need to check all the different permutations and do all the tests across the SCs

scribe: that is going to be cumbersome

Alastair - you can narrow the range down to 320 for reflow and apply text spacing

scribe: then identify the points in between for the breakpoints
... easier way to test is to zoom in through the range and apply text spacing

Chuck - overall there is going to be more testing

<Joshue108> I've a meeting running over will monitor on IRC

David - sounds like some organizations for text on top of images will have to do more testing

scribe: images of text doesn't have the problme

<alastairc> David, apart from 1.4.5?

<alastairc> Kathy: you can add text shadowing taht follows the lettering rather than rely on the background image colours. It does impact people, regardless of the SC.

<jon_avila> I have clients who just remove content rather than making it accessible. So you could make that argument for anything.

Andrew - it is increasing difficult to find cases where using images of text cannot be handled using CSS

<alastairc> David - I'd also suggest you can add background dark-fade that follow the text rather than the background

<jon_avila> They could also use an overlay box where the transparency of the background under the text is changed by changing opacity

<Zakim> gowerm, you wanted to say my bigger concern was resize and reflow being compounded

Mike - acknowledge there is more testing

scribe: reflow must be in all situations and with 200% text size may be an issue
... on ios the only way to meet is author based text size

<alastairc> https://github.com/w3c/wcag21/issues/850#issuecomment-385893206

<jon_avila> in my opinion pinch zoom is not AT. platform zoom -- 3 finger zoom is AT.

Alastair - jon was saying that pinch zoom is not AT

scribe: desktop browsers have 1024 px up and mobile 1366px and down
... don't think 200% text sizing at the base of 320

<gowerm> If pinch zoom is acceptable, we need to get that into the Understanding document

scribe: on mobile, you can pinch zoom to 200%
... in practice it is not an issue

Jon - there is at some point where you have 200% text size

scribe: as long as you can get it at some point on the desktop
... with the conformance note it is not as clear

David - cannot remove it, closed the issues

Andrew - I don't think we can remove it

scribe: it would send us back

<alastairc> Kathy: Can we add info to understanding to clarify?

<alastairc> AWK: Yes

David - most are testing mobile views

<marcjohlic> +1 to Kathy

<alastairc> Understanding docs - intersections of reflow, text size, text spacing, contrast (all), with regard to the conformance note.

<gowerm> So do we need a failure technique for where an author prevents Pinch to Zoom on a browser?

<kimpatch> Kathy: reason for putting that in was mobile views

<alastairc> gowerm - we can & should, although iOS (and I think Android) made it harder to prevent a while ago.

Andrew - when we have a view of the page that has 3 breakpoints; these are the variations presented and need to be tested under the conformance statement

scribe: alot should be the same but are testing the differences

<jon_avila> Yes, and the primary reason we need this note is because zoom forces the user into other variations with a link to a desktop page.

Glenda - this makes my stomach hurt about what is possible

scribe: we gained some efficiencies but the person testing often has not built it
... trying to keep track of what has changed and what has not
... I do think each view needs to be tested but realistically it is expensive

Jon - but that is my life, I am in different views

scribe: zooming I need to relearn where I am and what changed
... feel bad for the tester but user issue

Glenda - my vision without my glasses is bad

<kimpatch> i can scribe second half

<AWK> thanks

scribe: I am going to audiobooks

<kirkwood> ‘zooming’ and ‘resizing’ seem to be getting interchanged here? no?

scribe: I am looking at reasonableness
... it is not reasonable to test at different levels

<kimpatch> Glenda: we have to draw a line in the sand here – reasonable

<kimpatch> Glenda: what's the cost-benefit

<kimpatch> Jon: I have clients who take content off because of these issues – breakpoints

<AWK> Scribe: Kimpatch

Alastair: you can go through the details – mobile, what are your breakpoints, what disappears, what is transferred from one widget to another, what is missing at these breakpoints. So you can look specifically for these things

<Glenda> I’m totally on board with testing at each breakpoint. Yes. We need to test at each breakpoint. But it is not realistic to test at each pixel change of the viewport.

Alastair: you'll find things like the mobile navigation doesn't work properly – we find that all the time because people are not checking that. That's a real problem
... people using iOS will run into these things are different from the desktop – 131 failure. It's not a resize or reflow failure it's something else that is different at that breakpoint. So there's the deliberate ones and we really have to, for the non-deliberate ones I can't think of anything else apart from layout and text flow issues of the type that Jon's talking about where either content gets clipped or overlaps or different background contrast
... content disappearing – could just look at the tent poles of 200 percent bigger and 320 pixels, but it's not that difficult to load a page especially if you know what the deliberate changes are, zooming through the range and zoom out through the range
... because the things that come up are visually obvious

Glenda: if you can see the whole page – it's different when you're doing it on your own website when you know what's going on. But when we are doing it for clients, hundreds of pages, maybe a 10 second walk-through, we don't know what the deliberate changes are

Kathy: a lot of what Alastair said is what I was going to say – we need to check different breakpoints. In the conformant section – where we talked about testing in between is what Alastair was talking about. might not be 200 percent – you've now resized it and some points at those breakpoints decreased rather than increased
... you have to be able to test along that for certain success criteria. We can't say test at each of those different breakpoints because we can't test text size at 200 percent and test magnification

David: if there are three breakpoints and each has different sizes of text which is the baseline from which you have to multiply 200 percent to

<alastairc> David - the easiest answer is to say the largest breakpoint.

Andrew: that's what Kathy's talking about – if you're starting on a phone your constraint to your zooming feature, but if you're starting on a desktop think part of what Kathy was saying is that you start at the full desktop view and your zooming in and the layout changes – gives you a smaller text size than what you had – it might be that the testing and text sizes have to span multiple breakpoints. If each time you change the text keeps getting smal[CUT]

not get to 200 percent no matter what you do, then you fail

<jon_avila> I don't think one user mobile agent is sufficient

<Zakim> gowerm, you wanted to say it is a challenge of sampling

David: if you have enough contrast it will never fail at the 320 minimum

Mike: hope we come round the combination of resizing text flow. But my point is is a tester I always make decisions on sample sizes. I've got a thousand page website I'm not testing every page. I'm going to take a sample of it. I think the same thing is going to have to happen here in terms of deciding how to look at the permutations of combined sc's

<Glenda> How will people ever know that their site is compliant?

Mike: the value is if someone finds something it is an error and it's on the owner to rectify. You can't just say if one page performs that's what I need to do. So that's a good thing. The flipside is we get this confusion of resize and zoom. We're going to have to roll our sleeves up – I don't know if we will be able to create a scenario where every view will be able to go to 200 percent. But maybe for reflow the answer is we take it down to a browser wi[CUT]

320 across and you take it up to 200 percent there

Kathy: what were looking at is success criteria at three different break points – desktop, tablet, mobile for example, you are using that as your baseline
... have to be able to test the text size at 200 percent before the breakpoint because you can get into the breakpoint and it smaller. Have to have a point in time where you're looking at the baseline of that and then look at the text size of that from that point

<gowerm> Are the breakpoints such that it is feasible to get between the tablet and phone view and get to 200%?

Jon: just using iOS – that it works on a mobile is not sufficient to say it's going to work on a desktop.
... you could say the same thing with anything on mobile because the pinch zoom works very different than zoom on the desktop

<Zakim> AWK, you wanted to say we need to get volunteers to write clarifications for review and move on

Jon: agree about sample size – always samples always situations that are going to be out of our control. I think we are close. I would be willing to have an understanding note – how people interpret conformance – have that in the understanding document

<Kathy> I can help

Andrew: need someone to volunteer about writing for the understanding conformance. It's going to be more than conformance, we have to make sure things related to reflow and text sizing

<jon_avila> I can help -- but I need to understand our position

<jon_avila> We need to talk about orientation as well. Is that on the agenda for today?

Jon: Is there enough room

Alastair: what desktops don't have at least 800 pixels wide in terms of Windows-based

<jon_avila> That is Mike Gower speaking

Jon: when I get to that second tablet view I don't get the ability to magnify that at 200 percent before the phone view kicks in – it happens before that
... that will kick over to the other view

Andrew: that's what Kathy was talking about. the user would need to keep zooming in. They could ultimately get to 200 percent but they might not get it – even for desktop view, switches views and because of you switch changes the text size goes down again, and then keep trying to go up again, and then it goes down to the mobile, and then you keep zooming and eventually gets the text larger because there are no more views to change

Kathy: I think a couple of us work on the understanding and bring it back – we need to get this down on paper and have everybody go through it and say this is still not clear or add things to it. We have enough here to start.

Andrew: Kathy and Jon have indicated they are willing to help out with this, anybody else?

<Glenda> Yes please….so 10 experts would come to the same conclusion of pass or fail. Please no mushy test results. Looking forward to reviewing what Kathy/Jon/Gower come up with.

Charles: I can be a second reviewer after we've got something

RESOLUTION: Kathy and Jon and David (mike gower offered to review) will take a crack at understanding changes for the group.

Charles: don't offer charter allows for it but is it possible to state that acumulative effect is appropriate at AAA even if all these elements aren't AAA?

Andrew: we have no ability to do that now

Glenda: good idea Chuck

Issue 815 (https://github.com/w3c/wcag21/issues/815)

<jon_avila> yes

Andrew: Glenda and Jon do you have tools in your tools that test color contrast?

Yes from both

Andrew: refers to a specification that was superseded in 1999. The value that it should be instead of .03928 is like .04045 – something like that. It's very close
... the difference is they rounded something or didn't run something when they did the calculation.

<jon_avila> our results are consisent

<jon_avila> what does Gregg V say about this?

Andrew: are you aware of this – need to make the change at a later date, put this as errata…

<jon_avila> I see he replied but it sounds like there was not consensus

Glenda: obviously in the future we need to change it. As we go from .0392 .040 will more sites fail– if more sites fail we can't put it in 2.1

<alastairc> https://www.w3.org/TR/WCAG21/#dfn-relative-luminance

Andrew. It's just that the note confuses it

Andrew: do either of you have the ability to change a value in a branch of one of your tools so that we could actually find out how much of a difference this makes

Glenda: let me tap Wilco

Andrew: a spreadsheet with the calculation as well

Jon: it's not so much about changing, it's about running the data set
... probably putting in Excel and do it there. We could certainly change it and try it but it would be more like a manual effort
... more than that – it's in a definition, does that carry more weight – this is an arbitrary value anyway, I think consistency is more important

Andrew: 3.5 is a arbitrary value that the brightness is based in the science of it

<Kim_D> +1; I would like to understand the impact

Andrew: it would be nice to be able to figure out how much of a difference this makes and put in the understanding document how much of a difference it makes – we've been led to believe it will make a minimal difference, but we need to know that

Jon: specification doesn't reference the data – it's not really an errata
... we agreed not to around numbers

<alastairc> AWK - I've got a few in the Understanding listing that are ready for survey already, marked "ready for survey"

Andrew: we need you for next week if people have understanding documents that they feel are ready for the group to review for they have techniques that they want the group to review please send them to Alastair, Josh or me today or tomorrow morning so we can send out the agenda. We still have to send out the agenda for next week. We have to start clearing some of these things..

Marc: if I update my understanding document do I need to have it reviewed by someone before I updated in the understanding branch?

Alastair: make a pull request in the main branch. Good to have a quick review before merging.

<AWK> trackbot, end meeting

This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
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: AWK, alastairc, Kim_D, Kathy, gowerm, Chuck, jon_avila, Glenda, Laura, kirkwood
Present: AWK alastairc Kim_D Kathy gowerm 1 david-macdonald Chuck jon_avila Glenda Laura kirkwood
Found Scribe: Kathy
Inferring ScribeNick: Kathy
Found Scribe: Kimpatch
Inferring ScribeNick: kimpatch
Scribes: Kathy, Kimpatch
ScribeNicks: Kathy, kimpatch
Found Date: 03 May 2018
People with action items: 

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