SV_MEETING_TITLE -- 29 May 2018

Requirements document

<scribe> Scribe: LuisG

<jeanne> https://github.com/w3c/silver/issues

Jeanne: We got an email with comments on requirements document.

<kirkwood> agree with the reordering

Jeanne: Leonie is suggesting reordering the sections.

<jeanne> https://rawgit.com/w3c/silver/master/requirements/ <- Requirements draft

<jeanne> https://github.com/w3c/silver/issues/5 <- Issue

<chaals> [+1 to Léonie's suggestions.]

Jeane: here is Leonie's suggestion: I'd be tempted to reorder the content. Describing the principles before the problem space seems counter-intuitive to me. Describing the problem space, and then describing the proposed solution/design principles, feels like a better narrative to me.

Charles: Think she meant "requirements before problem space is counter-intuitive." Principles still makes sense as first thing.

Shari: I'm not interpreting it that way at all. Wouldn't we want the background, then principles, and then solutions.

Charles: These are overarching problems; higher than the principles themselves.

<kirkwood> agree with what Shari problem should be first

Shari: Weren't the principles developed because we knew what the issues were?

<kirkwood> sorry with agree with what Shari says problem should be first, then principals

Shari: Principles do more than just solutions to the issues...that's what the requirements are for

Jeanne: Can you live with putting problems first?

Charles: Now that I'm rereading the final edit of them, I think it does make sense. Some of them are rather explicit.
... which wasn't intentional.

Jeanne: What would you want to see as next step? Principles as next step?

Charles: Great question. I think next comment she made is even more important. I've tried to insert a few times...which is it seems heavy leaning towards disabilities rather than...I don't know the best way of describing range would be "disabilities or impairments in context of situations"

<imelda> +1

Charles: Leonie is concerned we're excluding people by just saying the word "disabilities" because it implies permanent disability. If we reword it to be less explicit about disabilities..

Shari: I think we need to be more explicit about the definition of disability, because nowhere does it say it's permanent. In fact more are temporary and not permanent.
... If we make it clear up front, don't have to worry about it excluding other people.

Charles: Think the solution is adding a definition?

Shari: It would be remiss of us if we don't say how it's defined. We don't want people to assume that all are permanent. And we don't want them thinking we're excluding a large amount of people.

<kirkwood> “impairment that substantially limits one or more major life activity” (according to US ADA)

Shari: we need to somehow make it clear what the definition of disability means.

Charles: I typically avoid listing any disability and use broader generic terms. But if we say what it means "herein" and how it's used in this document, it makes sense to say what we mean and then continue to use the word it should address the problem of people with disabilities being forgotten.

Jeanne: Actually, does WCAG have a definition of disability. I would use ADA, but it's US-oriented.

Charles: Core part missing in ADA definition is "moment in time." It's omitting that it can be temporary.

<kirkwood> To be clearer: “The ADA defines a person with a disability as a person who has a physical or mental impairment that substantially limits one or more major life activity. This includes people who have a record of such an impairment, even if they do not currently have a disability.”

Charles: Reordering the document makes sense. Having a definition inside introduction makes sense. So we just have to write a definition and reorder the sections.

<kirkwood> the current part speaks to what Charles was saying

Charles: It's a really interesting definition to say a person with a disability that no longer has is still considered to have a disability
... we're trying to make sure that access in the current tense is covered.
... Doesn't matter if I had and no longer have the disability. It matters that I can't get access.

MikeCrabb: We're not tryingto add for disability, but access.

Jeanne: WCAG doesn't have a definition of disability in the normative section.

<jeanne> The Intro of WCAG states: Web Content Accessibility Guidelines (WCAG) 2.0 defines how to make Web content more accessible to people with disabilities. Accessibility involves a wide range of disabilities, including visual, auditory, physical, speech, cognitive, language, learning, and neurological disabilities.

Charles: If we're listing them it's a challenge. But if we define that they can be permanent or temporary. Maybe it's "disability or impairment" or "situation or context"...

Jeanne: Maybe we say disability is a barrier. People have impairments, but the environment causes the disability.
... therefore anyone could have a disability.

Charles: I love the social model. It's not about the person. It's about the gap.

Luis: I like the social modal, but I've only ever heard it unofficially. Is it used somewhere officially?

<kirkwood> “impairment that substantially limits the use of the internet [major life activity]” ? -just a thought

Charles: The WHO uses it.

<Charles> An impairment is a problem in body function or structure; an activity limitation is a difficulty encountered by an individual in executing a task or action; while a participation restriction is a problem experienced by an individual in involvement in life situations.

<Jan> An impairment is a problem in body function or structure; an activity limitation is a difficulty encountered by an individual in executing a task or action; while a participation restriction is a problem experienced by an individual in involvement in life situations. Disability is thus not just a health problem.

<Charles> http://www.who.int/topics/disabilities/en/

<Jan> This is from the World Health Organization

<kirkwood> major life activty is how they defined , — sorry mic issue on my end

<Jan> www.who.int/topics/disabilities/en/

<Jan> jinx, Charles!

Charles: I have to drop off. I agree with reordering and adding definition as long as we can agree on one.

Jeanne: So this is a major new direction if we dive into a change of definition of something so fundamental.
... not sure I want to make a big decision like this.

LuisG: Agreed. I don't think we should make big decisions like this without both of y'all here.

Jeanne: Well we're supposed to be presenting it right after he gets back.
... If people could consider and think of definitions that would be useful for us. Please look to the Github issues page that I linked earlier and make comments in the Github issue that way our discussion is recorded and people can go back and review how we made the decision.

<mikeCrabb> http://accessible-reality.org/workshops/designing-for-accessibility-1.html

Mike Crabb: I did a workshop with developers...

Jeanne: I think the BBC people...well I have nothing but admiration for their work.

mikeCrabb: We looked at "disability challenge areas"
... we broke them up and then let people come up with how to divide them. Once I have more data I'll update.

<Jan> http://www.who.int/features/qa/50/en/... WHO's definition of e-accessibility

mikeCrabb: "intersectional" is if you have multiple disabilities grouped up what are the unique challenges that come up.

Jeanne: What's interesting is that it includes, "draws attention to the need to ensure access to ICTs for persons with disabilities on an equal basis with others and will help to eliminate barriers to information, including through the Internet"
... but I think we should leave this topic for now. Let people think about it and discuss it in the Github issues page. If we can put some of the definitions there that would help.

Project plan updates

<jeanne> https://docs.google.com/spreadsheets/d/10p-8-v-XqRllBaX_eTiXXvyyDYeft8GRiN3_11V3U0w/edit#gid=0

Jeanne: As far as prereqs, we're still struggling with Github. I sent an email to MichaelC asking to help us resolve the master branch problem we're having.

mikeCrabb: Are we going to have two separate branches?

Jeanne: Everything will be on gh pages probably. Everything we make will be HTML.
... okay, in the prereqs for things to do before June (later this week) we did the design spring report. Plain vs simple language has become moot because at the time we were struggling with it as a semantic issue and I think the direction we're currently going is experimenting with our own styleguide to see what's most appropriate for what we're trying to do.
... one of the things we haven't talked about is that we may have different levels of simple language depending on the audience.
... much of the guidance should be in simple language and we can recommendations of the level. When we're giving device to developers we should keep it as plain as possible but allow some technical terms which wouldn't meet styleguide for simple language

Luis: I think this makes sense as a way of operating.

<kirkwood> sure. we always used plain language guidelines in gov’t

<kirkwood> https://www.plainlanguage.gov/guidelines/

<kirkwood> granted that’s US

Jeanne: I want to mark this as complete.
... "finish the requirements" document. I'm going to push that off to June 12
... and the Github APIs is back on me...and Angela.
... AccessU is complete. GAAD is complete. ID24 in June? It's not something I added. Does anyone have a date for ID24 and is there any interest?

<mikeCrabb> https://www.inclusivedesign24.org/

mikeCrabb: The website for ID24 says the next one is in October and not in June. It was in June in 2017.

Jeanne: Oh yeah, we can make sure to do that.
... setting up pilot test of plain language work...John Rockford did a pilot test and Angela is reaching out to do another. So that one is in progress.
... writing the styleguide that will probably be an activity to start in mid June
... homepage design probably can't start yet since we're waiting for the information architecture
... prototype design I started last week. It needs more work and it's in Github but I'm not sure how you can see it. So let me get that in a way that can be seen.
... If we get conformance document polished enough to send out how do we want to do it? Charles said last week that he wanted to have different variations on it so people could compare and vote on different version of it. I think of it like a W3 person, you develop one thing, let people comment, make changes, let them comment again.

Jan: I'm concerned it would confuse people to have multiple options. Eventually you're going to have to go down to one document.
... not sure how we could have them different enough to have multiple options.

Luis: Do we have an idea of how large the conformance document would be?

Jeanne: Let me see if I can bring it up in rawgit

<jeanne> https://rawgit.com/w3c/silver/master/prototypes/ConformancePrototype.html

Jeanne: It worked!

Luis: We could maybe have it all in one document, but have multiple options of each section.
... well wherever we have sufficient enough of a difference in content as Jan brought up

Jeanne: Okay it's time. I think we're making progress. Hopefully we'll have the Github issues should be fixed on Friday

- DRAFT -

SV_MEETING_TITLE

29 May 2018

Attendees

Contents

Requirements document

Project plan updates

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output