<AWK> Scribe: Rachael

Survey on Essential cases: https://www.w3.org/2002/09/wbs/35422/essential_breakout/

Following up the discussoin on Tuesday, people wanted more time to read and respond. Our target is to provide 48 hours working day time to read and respond. We are focusing on providing that and it will impact what we have on the call.

If you are working on items in Github now, we need them by noon tomorrow to get them on a survey for the following Tuesday.

<AWK> https://www.w3.org/2002/09/wbs/35422/essential_breakout/results

<AWK> Items 2, 4, 5, 7, 9 are unanimous

AWK: On this survey, there are a number of items that are not controversial

The only change on these is to add the definition of essential.

AWK: given that these are unanimously agreed to and arguably editorial, will the WG agree to resolve these as a result of unanimous consent? Any objection to accepting 2, 4, 5, 7 and 9 as proposed?

<david-macdonald_> Test

<scribe> Scribe: David-macdonald

<AWK> Scribe: David

<david-macdonald_> Scribe: david-macdonald_

RESOLUTION: Accept 2,4,5,7,9

Andrew: now are on accessible authentication which doesn't have full approval from the group

We wanted to have Lisa on the call for this and Lisa responded with positive approval of this so it's okay for us to talk about

John foliot: my comment was more to the fact that we didn't have time to review it.

I withdraw my comment since I've had a chance to take a look at it

AWK: change the word essential to required

Jason: the other one was the complicated issue. This one is fine with me.

RESOLUTION: resolution to accept "In accessible authentication" as amended

In Adapting Text

Okay

<Zakim> steverep, you wanted to ask for resolutions

Steve: I can't find any examples in the comments or the list why the use of essential is necessary. Seems it was introduced back in March when the language was different
... nobody has produced any examples of where loss and therefore we don't have use the word essential.

Jason: unless there is good reason to put in a qualification then we shouldn't do so. If we know what the cases are we can craft the languages to be specific for those types of exceptions. But a wide word like essential diminishes the reliable testability of the success criterion.

Either remove the qualifier or turn it into something specific

This will help evaluators decide whether it passes or not

John: I tend to agree with Jason and Detlev, I don't think we need the qualifier here. For the user: some people could say that any content on the page is essential to them therefore there would be no qualifiers.

Brooks: this is just simply a situation of separating content from presentation

Andrew: I'm a bit concerned that if one is increasing the text size or the spacing or any of the four things that they're able to do in the success criterion

These are all things that take up space on the page, within a responsive design the design may be necessary to adapt to certain things

So if you have a menu system that has seven items there may have to be reasons to adapt A smaller number of menu items, and it obscures it behind a different user interface control

For instance we might be changing an image that is taxed adjacent to it that is why the insured which is replaced with just the logo. We want to make sure it's clear to people over try to follow this

What they can and can't do and I'm concerned

Jason: it would seem to me that the Zoom tax requirements which has to do with wrapping of content could be subject to the same type of issues in that case and

Raises the question of space visualization

These cases need very specific language if we think there a problem rather than having generic essential or some synonymous term qualifying the success criterion

If these areas of unclarity of what can be charged in response to a user's adjustment of various presentations parameters whether they apply to the zoom success criterion

As well or if we think it's an issue that requires clarification what would be the appropriate language to put in there. Seems like it could be put in a note below the success criterion

<Zakim> steverep, you wanted to say that, I may be wrong, but responsive designs cannot possibly respond to the Adapting Text changes

Or could go into a carefully defined terms, or various other ways of handling it. Are these the only types of cases we should be concerned about if not we have a well-defined problem

Steve: I don't want to discuss whom content when were not discussing changing that. But I think the cases are bringing up her more problem for Zoom content and not for this SC

These are just changes to the text and the author just accommodates it by leaving enough space in their containers. It's not going to jump to hamburger menu because the viewport has changed

So I don't think that's the problem here it's really just the size of containers and now these are overflowed

Alistair: we went through 50 websites and three ran the book marklet, and there were some issues but not many. But the general results were fine. We didn't find many problems with menu. Some of the things I was expecting to find. Anyone is done testing previously

Where you resize text to 200% is a recipe for disaster most websites this actually works on most websites

It seems like a good level of value to go to because were picking up things that should be considered bugs anyways

Because it's good to have buffers around text etc. at first I thought it was too much to ask for but now I've changed my position.

Detlev: can you explain this 120% value

Alistair: in adapting text is around letter spacing and word spacing. When you add up those values and apply it to sentence of text than it's about 120% of the original

Detlev: there may be more implications for other languages such as German where they have long words

<AWK> John, this is what this item is about. Not sure that this is in the weeds

<Zakim> JF, you wanted to suggest we're getting off into the weeds. The discussion is around the use of "Essential"

John: seems like we've gone off track without hundred and 20% I want to stay around issues of essential

<alastairc> My point was that if you remove essential, it doesn't really make it harder

Jason: so I think I might be wrong about this but based on this discussion, with this 120% of the original text size you only get some wrapping that will occur in some context

And in same text you really do have issues where the responsive designer might want to reorganize the interface to accommodate the increase in text size so it seems to me based on the discussion that Andrew has identified what would amount to

A relatively small issue for this success criterion at a relatively large issue for its occurrence and impact upon the Zoom text criterion

It would be nice to see a uniform solution to both of those if it's thought that some clarity is needed about what changes are an author can legitimately make to the content in response to

<alastairc> the short answer is: don't use fixed heights.

What changes they can make a presentation to in response to changes in text size or tech spacing introduced by user actions. If that seems to be an issue that we need a solution that applies to both success criterion where it's going to arise.

Michael: it seems like it's over complicating it. We are right now looking at were essential should be used and where it shouldn't be used while philosophically I agree

There should be a principal evidence needed here are not needed there but I don't think we should hold up the survey item offer up a gigantic issue.

<alastairc> Can we leave it as: Can anyone find an example of an issue? I can send around the testing, it was done for WCAG.

<alastairc> +1 essential not needed here.

Jason: I saw was my response to that is opposed to using essential or other qualifiers to overcome these types of problems because they're not specific enough about the kinds of cases that they're attempting to exclude

Michael: my understanding is that we are proposing to remove the qualifier essential not to replace it.

<Zakim> steverep, you wanted to say simply remove the word essential, and if someone comes up with a valid exception, then file an issue

Steve: can we just remove the word essential that if somebody has a valid exception case then file that as a separate issue and deal with it.

Andrew: I'm not sure I fully agree that essential doesn't make sense in this case

If you make a change as a result of adapting text and as a result some of the functionality or information is lost through the loss of some critical piece in that piece would be regarded as essential

That seems to be right in line with the definition which says if removed would fundamentally change the functionality understanding of the content

And functionality cannot be achieved another way that would conform

Steve: I think you're getting the negative mixed up it would have to be nonessential rather than essential
... no loss of nonessential content
... no loss of content or functionality occurs unless the losses to essential content. Something like that

<alastairc> In most cases the second part of essential screw it up, because "and information and functionality cannot be achieved in another way that would conform", because there would be other ways.

<Detlev> I changed by survey vote - I agree with the proposed change

<AWK> David: concerned about trivial losses of content triggering a failure

Jason: I think we can remove essential here and Andrew has a legitimate issue to file here separate

can someone take over scribing for a moment

<Detlev> I can take over

<Detlev> Scribe: Detlev

alastairc: Can send around spreadsheet with examples tested

<alastairc> Used 4 times in WCAG 2.0, 11 times in the new SC (from Steve)

<Zakim> steverep, you wanted to say 4 WCAG 2.0

Alex: there are no documented abuses of the term essential in 10 years of testing WCAG - probably not a problem

Steverep: WCAG uses essential for clear exceptions

<david-macdonald2> scribe: david-macdonald2

Steve: it seems like we are using the word essential is a comfort to ourselves and I think we are neglecting the second part of the definition

There are 11 instances of it in the new success criterion where it's only used four times in the entire wcag 2

<Detlev> steverep: Many more introductions ion new SCs, kind of a comfort zone - no clear evidence that exceptions are needed

Andrew: it shouldn't be a surprise at his coming up or in this version because were dealing with a bunch of harder issues

The 2.00 is a lot more of the core issues that we know about. And the new ones are issues that we struggled with in 2.0

<Detlev> AWK: no surprise that it comes up more often in 2.1

Jason: want to agree with Steve's analysis

<Detlev> Jason: agrees with Steve's analysis: is much moe problematic for reliable testability in WCAG 2.1

My wider concerns about reliable testability is being backed up by research into the reliability of expert ratings of webpages and applying our standard

thanks devlev, I'm back in, i was crased out

<Alex> Detlev, i think it is you who is typing hard on the phone. please mute your line

<Detlev> Jason: We should strive to limit to its use not to give authors too much leeway to interpret it in different ways

Jason: I'm afraid that this will diminish the testability of the standard compromise the standard
... let's craft exceptions more specifically

I'm trying to restore the decline in the overall testability of the standard

<Detlev> Jason: Be clear when we really need it, then define the language very clearly

Seems to me we should be able to remove it, but I agree that Andrew may have concerns which could be specifically addressed separately

<Detlev> Jason: Understands Andrew's concern though

Andrew: are we willing to say yes we will remove essential here with the recognition that we may be bringing this back when we get more data.

Is there anyone that disagrees with that approach?

Alex: I don't know about that

I don't think we have consensus

Andrew: I'm not sure we have consensus so for right now let's leave this one open and we can move forward

CONTENT on hover or Focus

<alastairc> Testing spreadsheet for adapting text: https://docs.google.com/spreadsheets/d/1LRsAtLReBL6LnbvJQ4biQ1ER1fKbh8MDWnHqbsW7B1o/edit?ts=5975fc92#gid=1060062606

Andrew: this is about the word essential also, and replace it with other than pure decoration. There is a lot of questions in the survey

<JF> s/other than peer decoration/other than pure decoration

<Zakim> steverep, you wanted to try to quickly respond

Steve: it has a definition as Michael says and I think it reflects the concerns that people had.
... I think there is a different but it is subjective

Pure decoration is no information or functionality

For Alex's concern, it's not a question of nothing can obscure anything it's only about the control that triggered it

Alex: does that mean when you propose this that you mean peer decoration within the trigger or pure decoration in all screen. What is the scope

The problem comes in my near close to it at your mouse is close to it you can't help but true. Many can obscure the trigger

Alex: icons have borders they are not pure decoration they are there for a reason but are not essential

It's really hard not to cover-up the border, so that you invest in that grey area that were trying to use, I'm not covering anything within the icon itself that is important I'm discovering a little bit of the border yet I fail of the success criterion

Even with that little case I would fail

Steve: I would say that border is pure decoration in that case

Alex: it is not pure declaration the border has functioned it tells you when you will trigger and when you won't trigger information. It's not essential but it is not decoration so there is a gap

<Detlev> I think there are cases where stuff has double encoding like an icon followed by a text link - it may or not bwe Ok to cover the icon here

RESOLUTION: leave open

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)

Succeeded: s/folio:/foliot:/
Succeeded: s/RESOLUTION: resolution to accept as amended/RESOLUTION: resolution to accept "In accessible authentication" as amended/
Succeeded: s/Andrea/Andrew/
Succeeded: s/peer/pure/
FAILED: s/other than peer decoration/other than pure decoration/
Default Present: AWK, Rachael, steverep, MichaelC, jasonjgw, alastairc, Brooks, JF, Pietro, Detlev, kirkwood, david-macdonald
Present: AWK Rachael steverep MichaelC jasonjgw alastairc Brooks JF Pietro Detlev kirkwood david-macdonald
Found Scribe: Rachael
Inferring ScribeNick: Rachael
Found Scribe: David-macdonald
Found Scribe: David
Found Scribe: david-macdonald_
Inferring ScribeNick: david-macdonald_
Found Scribe: Detlev
Inferring ScribeNick: Detlev
Found Scribe: david-macdonald2
Inferring ScribeNick: david-macdonald2
Scribes: Rachael, David-macdonald, David, david-macdonald_, Detlev, david-macdonald2
ScribeNicks: Rachael, david-macdonald_, Detlev, david-macdonald2
Found Date: 05 Oct 2017
Guessing minutes URL: http://www.w3.org/2017/10/05-ag-minutes.html
People with action items: 

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