<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.
<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
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/Mike Crabb: We're not trying /MikeCrabb: We're not trying/ Present: mikeCrabb kirkwood LuisG Charles jeanne Jan Shari Imelda Regrets: chaals Found Scribe: LuisG Inferring ScribeNick: LuisG WARNING: No meeting title found! You should specify the meeting title like this: <dbooth> Meeting: Weekly Baking Club Meeting WARNING: No date found! Assuming today. (Hint: Specify the W3C IRC log URL, and the date will be determined from that.) Or specify the date like this: <dbooth> Date: 12 Sep 2002 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.)[End of scribe.perl diagnostic output]