<Brooks> scribe: Brooks

Silver Requirements (https://www.w3.org/2002/09/wbs/35422/Silver_Requirements/results)

awk: TOPIC: Design Principles

Design Principles

<alastairc> Ah, the results doesn't have the changes, but the original survey does: https://www.w3.org/2002/09/wbs/35422/Silver_Requirements/

awk: Marc has reservations about including two specific disabilities types.

Marc: I see that Alastair called these two out because they don't necessarily follow the pass/fail model. Should there be an explanation on why low vision and cognitive groups are called out?

Jeanne: Sure, we could say something along the lines that explains why.

Alastair: I'm not sure that we should included that in this document.

awk: Marc, sound OK with you?

Marc: Yes

awk: Mike Gower provideds the most comprehensive review of the language in the Silver Requirements in his survey response. Jeanne or Shawn, what are your thoughts?

Shawn: We can address those.
... We should not require large amounts of research from large amounts of people. We don't want that block people from discussions of accommodating various disabilities due to a lack of lots of data.

awk: The research should be evidence and data based, but it shouldn't require that we draw on large numbers of people as a basis for including their needs in Silver.

Shawn: We can look at how we can adjust the wording that makes that clearer.

awk: Anyone else have questions about the Design Principles?
... I have a question. What does it mean that the process to create the guidelines should improve the ability to support automated testing?

Jeanne: There were comments we've received that said that if we had adjusted some of the language in the previous standards, it would have been easier to facilitate automated testing.

awk: I wonder if this would make more sense in the Accessibility Guidelines "should" section?

Jeanne: If we put it in the "should" section, it may be hard to optimize guidance for specific Guidelines.

Shawn: This isn't saying that each Guideline requires automated testing. I don't feel strongly as to which section this information belongs in.

<alastairc> That aspect didn't bother me, but it leads into the points I did have.

awk: I agree that we don't want to have firm requirement that everything in Silver must be capable of being automated.

David: Low-vision and cognitive disabilities were called out because of gaps in coverage in WCAG 2.0. Now, I think the larger gap is in the cognitive disability area. I think we should drop low-vision, and just include cognitive.

Jeanne: We've had some comments that make me want to leave low-vision in there.

David: Would like to add "without compromising clarity" to the plain language requirement.

Jeanne: It sounds a bit redundant. Plain language for many means clearly written.

<kirkwood> +1 to David

<alastairc> testable should mean accurate...

David: As a recap, because the Low Vision Task Force is not pursuing any additional Success Criteria in WCAG 2.2, and because much of the gap in coverage for low vision users was addressed by WCAG 2.1, maybe we should drop low-vision.

<laura> suggest consulting with LVTF before dropping LV from principles.

David: I'd like to see that the accuracy of the language is a requirement that should not be dropped because of the need to provide plain language.

Laura: It's my impression that the low vision task force should remain as a group specifically called out in Silver.

Alastair: My impression was that the low vision task force was interested in looking farther ahead than WCAG 2.2 to continue to address user needs.

awk: Should number 10 be moved up into the top section? Anyone else have thoughts?

Shawn: I think we got to the point that we are going to do that.

awk: Anything else that's currently outstanding? Any new comments for the Design Principles?
... It sounds like from the survey and the discussion that everyone can live with these.
... Any objections to accepting the Design Principles as amended?

<alastairc> +1 to accept design requirements

<Detlev> +1 ok with that

<Rachael> +1 to accepting

<AWK> +1

+1

<JakeAbma> +1

<Chuck> +1

<laura> +1

RESOLUTION: Accept Design Principles as amended, pending changes we've discussed

awk: TOPIC: Introduction

Introduction

David: I think we need to remain focus on addressing the user experience for people with disabilities. I think we need to use the word "episodic" instead of "situational."

<AWK> From the intro: People with disabilities can face problems using online content and applications. Disabilities can be permanent, temporary, or situational limitations.

<laura> +1 to changing to ”Disabilities can be permanent, temporary, or episodic."

<kirkwood> +1 to David… “situational limitation” isn’t really a disabiliy and clouds things

David: Talking about situational disabilities shouldn't be what we focus on. I'd like more clarity on that.

<kirkwood> episodic recurs

awk: What's the difference between "episodic" or "temporary?"

<Jon_avila> I agree with David

<kirkwood> +1 to david’s description

<kirkwood> but can recur

David: I think of episodic like someone who has arthritis that flares up from time-to-time, whereas situational sounds more like a temporary state.

<kirkwood> episodic recurs, temporary may not

Jeanne: We've received feedback that some users have limitations, but the barriers are present the disability. I think that's what's at the root of why we included "situational."

David: I'm bit troubled by the broad nature of "situational."

Jeanne: We've included "situational" only in the introduction. We used it because some people with disabilities wanted that word included.

<alastairc> I thought 'situational' has been used to expand *beyond* disability, rather than a type of disability, as part of a benefits pitch.

<kirkwood> permanent, temporary or recurring

awk: Permanent and temporary covers a lot of ground. It seems like "situational" is a subset of "temporary""

<david-macdonald1> https://www.w3.org/WAI/EO/wiki/Situational_Limitations_References

awk: Sounds like this is something that the Silver Task Force can take up for further discussion.

Requirements

awk: There were changes to 1,2,3,4,5,6 and 8. No changes for 7.

<david-macdonald1> It appears that references to situational seem to be almost exclusive ly referring to people who don't have disabilities, but have a situation that benefits from the accommodation (that was initially intended for pwd)

Jeanne: I wanted to address the communications issues with GitHub. We need to work on our communications. Someone from our side likely dropped the ball. Can't speak to the issue of it taking seven years to do a re-write.
... With respect to Jake's survey response, I feel that we still need to leave things flexible at this point in the process. The "where appropriate" there is not being imprecise, it just acknowledges that different guidelines need different treatement. "Understandable by a non-technical audience" was put in by request from suggestions we've received.

Shawn: The overall goal for being understandable by a non-technical guidance is to make the general guidance understandable without having to understanding underlying implementation details.

awk: The title of the requirement is "Technology Neutral." I feel that this means that the guidance should be technology independent. What do others think?

MichaelC: I don't think we are at the point where we are ready to bake guidelines and methods in at the requirement level. I'm worried that alternatives haven't been fully considered.

Shawn: I going to make a note to see that we can improve that language.

Jeanne: If we rework it too much, it will likely cause delays and require a new vote.

<AWK> WCAG 2.0 language for this item was "WCAG 2.0 requirements should be expressed in generic terms so that they may apply to more than one markup language or content format."

<AWK> WCAG 2.0 language for this item was "WCAG 2.0 requirements should be expressed in generic terms so that they may apply to more than one markup language or content format."

MichaelC: I don't see this as a major change, or as a cause for delay.

awk: The WCAG 2.0 requirements were pretty straightforward. Something like that in Silver would provide enough structure to do what we want, without getting into guidelines versus methods.

Shawn: The specificity came from the working group because they want to know what do I have to do to meet this?

awk: To Michael's point, the requirements are going to be expressed in generic terms, with a technology layer that provides greater specificity.

<laura> suggest moving the second sentence of 3.1 from the requirements section to principles section.

Laura: I'd like to move the second sentence of 3.1 into the requirements.

Alastair: I don't think "where appropriate" is wishy-washy.

<laura> Hope AC is right. May be lots of disagreements.

<alastairc> Suggested: "can be used where appropriate..."

<david-macdonald> scribe: david-macdonald

Laura: the first sentence is the requirement in the second sentence is providing a principal

Jeanne: it kind of loses importance that we are changing our approach from WCAG. If we don't have the first sentence that matches the title. In the title is what we want

Laura: that's probably where we disagree

AWK:

Jeanne: no. Everything has tests and there may be multiple types of tests depending on the requirements so that there are still ways to measure it. In some cases there will not be true false success criterion.

Most of the existing guidance will still have a true false test but some of the new requirements will have other ways of testing where it's appropriate for such things as cognitive

AWK: do we have any examples

Jeanne: yes we do have examples I'm trying to think where they are and call them off the top of my head. Well the most basic when we use all the time for quick testing of things is for all text

To see if all text exists but you also want another test to see if the all text is the most appropriate for that image. For the example John folio gives. You can use the word image of the alternative text but it doesn't provide the equivalent experience

How would we do that. We would use a rubric that under these circumstances what would be appropriate

Poor wouldn't pass any okay and exceptional would pass

JF: it's introducing the notion of context is really what it is. And we also ready sort of do that although it's not called out in any of the 2.0 success criterion's anybody who does 1.3.1 needs to use context

At times there needs to be that flexibility or kind of feels right. There is some subjectivity to fully determining the appropriateness of something I guess

AWK: does that mean there is. Going back to the alternate text example doesn't seem to be multiple ways to measure something. It's more like the evaluation is nuanced as opposed to the measurement.

JF: testing is different than measurement you can test mechanically for the true false and then you have to manually evaluate the quality of the alt text. So there are two parts to the evaluation mechanical and manual

Down the road we could see from our sites artificial intelligence could be used to ensure the alternate text is appropriate in context. So there's multiple methods of testing are evaluating but the goal always remains to be essentially the same

AWK: that's true of a lot of things we have today so I'm

Alastair: I think we do need the second sentence because it's saying how it's expanded. I would quibble that user research would be verifiable but that's comment for another time. But I can see the need for, for instance if we want to have the quality of all text be in a sliding scale we need to have some nuance in that language

JF: perhaps the word measure is not the right word perhaps the better word would be evaluate but I'm not sure

AWK: is the core of this idea being that certain types of things there will be a sliding scale of quality for the result

JF: I don't want step over Jeanne but that's always been my understanding that it goes hand in hand with the significant but not perfect. We all know that perfect is not an elusive goal so were already thinking about a sliding scale about a reporting so it seemed to me that this would go hand-in-hand with the evaluation process.

Jeanne: it is our way of addressing some the cognitive needs that are not able to be included in WCAG because they couldn't apply to a true false situation. So for those things that really don't work with true false giving them a sliding scale and including part of the scale that fails part of the scale that passes

Laura: perhaps I should the title for 3.1. A sliding scale to evaluate

Jeanne: it's a bit too restrictive because some things won't be a sliding scale.

JF: a two point scale is technically correct pecan facility so we would be using multiple ways. Maybe measure is not the right word.

Jeanne: perhaps the word is test

JF: what were really means we want to get past the true false evaluation where there is room for multiple shades of grey.

Detlev: I think it's very hard to discuss these things without actual examples. But when I saw task completion is 1 Possible Way that would enter measurements. Has the Silver group thought about the interactions between the idea of conformance focusing on a page and task completion which is usually across a process which might be several pages.

There is a potential conflict which I see. As been discussed.

<Zakim> JF, you wanted to address "pages"

Jeanne: we haven't discussed that in a lot of detail because were caught up in what were doing right now. The page evaluation is not useful in the application based products and for mobile products and software-based products. So we want to look at the project or product level and let the organization that wants to claim conformance to find what that is in their scope

Large companies will often break down their products, into multiple sections when they're claiming conformance and we want to support that

We have some detailed information that Charles Hall has produced that says this is the basic procedure that you must document than they would give the task completion results in that those results could then be reapplied to a sliding scale or distance from the mean or other ways that specialists and task completion testing could do this is beyond my expertise

People who are specialists in this have worked out a lot of details on how to measure and test on these different methods

Detlev: it's good not to lose track of anything that is precise that could be used. So if there is URL it should be recorded and if there are steps to get to a certain state there should be steps listed that kept you to that state.

The danger in giving up the page model is that you get something is very difficult to reproduce you don't know where to get there and how to get to the state that were actually being evaluated.

Jeanne: they've talked about that. Part of the requirement is that they have to document what they did so that I can be reproduced externally

Detlev: okay

Jeanne: we definitely want to be reproducible. Charles Hall wrote a very good document on heuristics testing which is linked and all find the link

JF: I've similar concerns. I share your perspective and I talked about pages as well. At DQ we've moved into talking about screens because we see multiple's greens single page applications were all the content is being reflash dynamically. The URL doesn't change it's a single page app

<jeanne> Charles Hall's proposal for Heuristics testing <- https://docs.google.com/document/d/1lEkht-bhkaPMzOojWpDjZhbnGeckiYLh-J4-ze7cGS0/edit#

So the page metaphor while useful is already becoming kind of broken so we need to think beyond that. I think you have a good point when you talk about evaluation reports

In the case of interaction flows where there might be no multiple screens to get to the sign up for newsletters. We evaluated task and it must be detail sufficiently so can be repeatable. The other thing is is that I think a lot of people concerned with the WCAG conformance model as it is right now because most people one site conformance statements not page conformance statements

When you look at the V PATS that I being used in North America. They are at the site level not at the page level. I don't know if pages are a metaphor anymore.

Jeanne: especially for moving on to mobile apps etc.

AWK: there definitely seems to be some concerns about just how this initial one is actually saying. Let's put to the side for a moment and try to get through the rest the comments. And see if there's any other main things.

<Detlev> present is fine

AWK: Looking at Michael Gower comments.

<Jennie> +1 to present

Jeanne: I accept those friendly amendments

AWK: Looking at Alastair's comments on the requirements section

Alastair: Seems like there's a gap in the requirements. Such as making sure that it's required to work across different sizes of organizations. National government bodies down to personal blogs. For instance a task-based thing will work well in an application but not so great and in a to Z of products. My solution to that was to provide support and how to apply conformance across different types of organizations

Jeanne: I think we had that somewhere

Alastair: I read the whole thing and I didn't see that explicitly

Jeanne: it's not jumping out to me either so maybe that has been removed for some other reason. It's always a danger of wordsmithing is that you end up losing something that's important that work elsewhere.
... we'll have to find where was and how we can put it back in a way that works

AWK: it feels like a lot of the questions brought up in Alastair's comments looked conformance. Or whether conformance roles up to a site or a page or being able to make a more nuanced claim about whether something conforms or not.

Alastair: there are good things happening regarding user agent requirements etc. But based on our focus visible discussions you could as an author saying I'm relying on the user agent to do this but but the guidelines do need to be able to set responsibility for the author had a particular level so there might be a range of options.

Something I was is not explicit in WCAG, we have where you as a review author are responsible. It may not be ideal at the technique level but we have to provide a set line of responsibility. It is conformance but is something that's not explicit in this document right yet

Jeanne: it's not explicit because we haven't worked out the details. We talked about it were very aware of it that we have to do it is a huge part of the research results. Whenever we interviewed people are about survey results from people at the sophistication to look at that issue it also popped up very high in the results

So we definitely want to do this but exactly how we don't know. We have a pretty good idea how we want to do about outfits in a broader pictures where we don't want to say alright bring to put this in the requirements now because we this is how we know working to do it.

AWK: you say you know you have to do that can we say that in the requirements.

Jeanne: if we make it general enough that it's rejected because it's not precise enough but if we make it specific that it's too prescriptive

AWK: is there a case where you've tried to say that a Broadway where it's been rejected

JEANNE: spending all of the slide decks and presentations redone of the group.

A WK: so that would suggest to me that it's probably something that we should have a requirement about.

JEANNE: but look at what were going through with technology neutral. We worked on a we forget how we are going to do we put it in the document it was too vague and everybody said it's going to make it more specific. When we made a more specific then it's criticized being too prescriptive

We'll have another version of the requirements in the fall when you can look at everything together. We definitely want your expertise where were making mistakes. But don't make us put in the requirements document right now if we don't how to do because we get in this wordsmithing spiral

AWK: speaking just for myself that's not how requirements work in my view.

Jeanne: you're holding us to a higher standing then you're holding yourself.

AWK: I don't think this is productive

JEANNE: Sorry.

AWK: Laura and Alastair have some comments. Let's see if we have some edits that can satisfy the commenters.

Alastair: I can appreciate the requirements this is for earlier parts of the document. It's coming from, there's quite a bit of information before the requirements and just putting out two things that seem like gaps to me

AWK: I agree with what you're pointing out

<jon_avila> Maybe we could put in a note that it's something we'd like to address as a placeholder?

JF: I think part of the things that the responsibility piece. Kind of working through this. One of the goals is that were also hoping. Jean correct me if I'm wrong. But one of the goals is to work back into you UAAG Atag territory
... I'm very concerned about scalability measurability and all those kinds of things and I recognize it's still a work in progress. Basic principle moving forward as this will resetting how to do yes the devil is in the details with details of not been worked out yet.

<Detlev> +1 to Mike

Michael Gower: can't see anybody saying they can't live with it

Alastair: these two ideas have been percolating in my mind for quite a while.

David: with the purpose of the requirements document are we formalizing the silver work for inclusion in future work for the working group.

AWK: yes that's right

Does this vote on these requirements mean that were actually going to formalize our work on Silver and this is the direction were taking.

Alastair: my concern is that if it's not a requirements document it's a lot weaker argument if you reject something later

Detlev: I think a lot of the proms in the services for cannot be properly predicted right now basically when we talk about rubrics and scales and task-based measurements and so on. There's a whole bunch of new stuff which is basically useful which I've always been a a critic of pass fail so in general I mean quite in favour of it. And how it'll work out will be easier to discuss as we get closer to an actual system

which is easier to measure unreal sites with those problems will become much easier ... So I think we should go forward in we don't need figured at all today.

JF: I want to see conformance model and one of the things I've come the conclusion of is that it's still too early in the process to be talking about it. What we have here is. I see these are our guiding principles as we move forward. There's still a lot of work that needs to be done. Which is part of my side rent that we will be ready in 2020.

But the principles of what were trying to articulate here are good enough guidelines and bumpers to keep us moving in the right direction. Organ have to test some hypothesis from time to time as we really start to build things out. But to think that were at the point where this is defining conformance model. I say were six months to a year ahead of having something that we can ask to talk about its conformance model.

<Zakim> laura, you wanted to ask how difficult would it be to change the requirements later?

Laura: how difficult is it to change requirements later

AWK: it depends when later is. For taking the vote to send something the candidate recommendation then it's an insurmountable if later is after an editor's draft comes out then it's certainly possible but it does start to make it more challenging.

Alastair: my understanding is that part of the charting process including silver is included in the charter. It's a requirements document that would be going out as part of that package of information for the AC committee to review

Laura: so would be pretty well set in stone at that point wouldn't.

<scribe> scribe: david-macdonald

I think we need them now because we do need a guide

We don't need to consider them so frozen that we can adapt

Previous comments by Michael Cooper

<jon_avila> If we know something will be a requirement but we don't know how -- we should put a note in indicating that we do know it needs to be addressed but have not worked out the details.

JF: Michael use the word guide. The context of the question that Laura posed looking at six basic requirements or guides. So I would ask do you think there's something at the 300 foot level that we would miss. To think there's something you need to be added. Some of these things need to be about malleable

I was on a silver colour there today where were starting to look at the migration process but we have even started migrating any the success criteria yet.. Unlike unreasonable to come back to the group and say that in the practice we found this. Is still a bit hand wavy I think we've covered all the main points but now we need some changing

<Zakim> AWK, you wanted to suggest to approve them now but ask for an update in a month on conformance related issues

JF: Alastair's expressing concerns but that were just watching closely

<Detlev> AWK what is the actual proposal?

I'm getting kicked out all the time here

<scribe> SCRIBE: David

<laura> +1 to awk

Jeanne: I'd be happy to come in once a month. A part of the problem is that if we continue to keep discussing the issues as part of the requirements were not getting the other stuff done.

Today I was can do some more work in the conformance part but now I'm going to be spending that time updating the requirements document again.

So there is a certain point where I'd like to request what we want to use the requirements documents for us to get the general agreement of the group that we agree with the principal and the directions were going that these are the things we figured out and we want to do this

So we can actually start putting into a document you can see with more detail we can flesh out the conformance stuff. But ask we continue to cycle on the requirements as I would like to ask the group to agree that what we have so far there agree with these directions and we should continue to push this forward

<Detlev> +1 to Jeanne - let's move on (let them move on)

That in a month let us show you where were at the where we've gotten to

Rather than trying to work out all the details in a generic way that we don't know yet. It feels like a waste of time to me and I'm feeling really anxious that we want to have an editor's draft on

And work spending time on the requirements and the speculation of the requirements or wordsmithing.

Can we just move on from here?

AWK: can we agree on the requirements as they are as amended from today but to ask for an update to the requirements to address some of these gaps and points of the been made in a month

Is anyone disagree that that's a good approach?

Alastair: I think that we can have regular updates but it seems like the next time to evaluate is when the conformance model is been more fleshed out.

AWK: the point of my proposals based on what I'm hearing is that people do want to have clearer guidance to help with the development of the conformance model.

JF: the conformance model assign my radar also but it's tough and we know it's good be tougher a long time to think what we have freak requirements right now is that it's a guide but not a map
... I be concerned if we have a deadline for conformance model in the next month or two

AWK: I don't think anyone is saying that.

We had confusion on this call about multiple ways to measure what that's actually saying in the general gut feeling that I have from people that the Silver task force knows what they mean by it and people on the call of raise the idea that they're not sure that they do understand

It's almost like saying we trust the task force but we want them to come back with an update on how these can be treated so there's more clarity

JF: I think as we go through the migration process we can have some examples were begin do some show and tell that's where we can do the pointed probing.

Right now are having a hypothetical conversation with applicable thing that we don't have anything to look and so it's really hard to critique something that doesn't exist.

Jeanne: were hoping to get outside expertise on the conformance model where we get people that has expertise where we don't for the conformance model probing to get an antenna and with at least three success criteria.

<Detlev> Shall we have a quick strwa poll in overtime still?

Jeanne: I'd like to show you in a month a conformance model with existing success criterion and this is what we have to show you what you think. Then if we need to look back requirements in great. But I'd rather start showing you stuff and have hypothetical conversations as John put.

<laura> Need to drop off the call. I am fine with whatever the group decides. Thanks to Jeanne and Silver TF for all your hard work.

AWK: is anyone who feels like they object to approving the requirements as is or is amended today which will then have them go to CFC?

<Detlev> no objection

<alastairc> Happy to approve, noting that I will be thinking about the 'gaps' I noted during reviews of conformance models...

<mbgower> Speaking of something that doesn't exist, when are we going to cover all the holes in techniques for 2.1? Growing increasingly concerned that we're spending all our time looking forward when the 'current' 2.1 guidance is clearly inadequate

<jeanne> I'm glad you are thinking about the gaps. It's very helpful. I just don't want to put the gaps into the Requirements,

<mbgower> no objection

<JF> no objection

<mbgower> As per my last posted comment, can we please spend some time completing 2.1?

<Mike_Elledge> no objection

RESOLUTION: Accept requirements as amended

RESOLUTION: Accept requirements as amended, send to CFC. Some concerns noted.

<kirkwood> tough crowd

<AWK> trackbot, end meeting

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)

Succeeded: s/"episodic" or "situational?"/"episodic" or "temporary?"/
Succeeded: s/general guidance is/general guidance understandable/
Succeeded: s/I want step over Jean but/I don't want step over Jeanne but/
Succeeded: s/except/accept/
Succeeded: s/and see anybody seeing the/can't see anybody saying they/
Default Present: AWK, Jennie, Chuck, MichaelC, alastairc, JakeAbma, JeanneSpellman, stevelee, Brooks, Lauriat, Rachael, MarcJohlic, Kathy, kirkwood, Raf, Laura, Detlev, mbgower, JF, david-macdonald, Mike_Elledge
Present: AWK Jennie Chuck MichaelC alastairc JakeAbma JeanneSpellman stevelee Brooks Lauriat Rachael MarcJohlic Kathy kirkwood Raf Laura Detlev mbgower JF david-macdonald Mike_Elledge
Regrets: Bruce
Found Scribe: Brooks
Inferring ScribeNick: Brooks
Found Scribe: david-macdonald
Inferring ScribeNick: david-macdonald
Found Scribe: david-macdonald
Inferring ScribeNick: david-macdonald
Found Scribe: David
Scribes: Brooks, david-macdonald, David
ScribeNicks: Brooks, david-macdonald

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 23 Apr 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.)