W3C

Accessibility Guidelines Working Group Teleconference

11 Mar 2019

Agenda

Attendees

Present
AWK, Cyborg, Chuck, Rachael, jeanne, Lauriat, JF, corbb, JohnRochford, Laura, Brooks, Katie_Haritos-Shea, bruce_bailey, JakeAbma, MarcJohlic, Glenda, Makoto, shari, AngelaAccessForAll, RedRoxProjects
Regrets
Chair
AWK
Scribe
Brooks, LuisG

Contents


<laura> Hi, Andrew.

<jeanne2> we aren't starting until half past the hour.

<jeanne2> s/we aren't starting until half past the hour. //

<Cyborg> sound good so far

<Cyborg> furthest person hard to hear

<JF> agneda?

<corbb> Can I trouble you to add me to the W3C Community Group? “corbb”

<AWK> https://www.w3.org/2017/08/telecon-info_ag-ftf

<Cyborg> what is that link to? not working for me...

<corbb> 404 error for me @AWK

<laura> yes

<Cyborg> yes hearing

Housekeeping (Sponsors, breaks, lunch, dinner, etc)

<AWK> https://www.w3.org/WAI/GL/wiki/Main_Page/CSUN2019_teamdinner

<Chuck> worked for me Bruce, so apparently not a global issue.

<Cyborg> can more people please join webex - very hard to hear others in room

Silver Requirements (joint meeting with Silver TF)

<Glenda> scrbe: Glenda

<jeanne2> https://w3c.github.io/silver/requirements/index.html

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

<Lauriat> Silver Requirements (current draft): https://w3c.github.io/silver/requirements/

<Glenda> AWK: we could talk about the requirements forever. We are not here to do the refinements/word-smithing.

<Glenda> Shawn: Opportunities for Silver is to give context. That is why we didn’t ask for feedback on that piece.

<Glenda> Shawn: Design Principles vs. Requirements. Requirements that are measurable are for Silver. Design Principles are framing the objectives for Silver (may not be measurable, but are guiding principles)>

<Glenda> Shawn: keep discussion focus on “do we want to include this?” “Is there anything we need to clarify?” We will assign clarification work to be done outside this call.

<Zakim> AWK, you wanted to ask what is the difference between a design principle and a requirement?

<Glenda> AWK: I’m a little confused about the difference between Design Principles and Requirements.

<Chuck> We lost audio.

<Chuck> Or I did.

<laura> no audio

<Chuck> audio back

<laura> yes audio back

<Lauriat> Deep link to the Design Principles: https://w3c.github.io/silver/requirements/#design-principles

<Lauriat> Deep link to the Requirements: https://w3c.github.io/silver/requirements/#requirements-0

<Glenda> Jeanne: Requirements are measurabe things to take into CR to see if we met CR process. Design principles are the guiding principles.

<Glenda> AWK: okay. Requirements are measurable. Design principles are loser.

<Glenda> Shawn: Design Principle 1: “Support the needs of the widest range of people with disabilities and recognize that people with disabilities have individual and intersectional needs.”

<Glenda> Katie: What are the measurable pieces?

<Glenda> Katie: For compliance purposes.

<Glenda> Jeanne: Those are the Requirements.

<Lauriat> Survey Results: https://www.w3.org/2002/09/wbs/35422/SilverRequirmentsReview/results

Design Principle 1

<Zakim> Brooks, you wanted to ask what does "intersectional" mean?

<Glenda> Survey results strongly in agreement.

<Glenda> Brooks and AWK ask for clarification of the word “intersectional”.

<Cyborg> v hard to hear microphones

<Cyborg> can't hear any mics, so notes would help a lot.

<Glenda> Shawn: intentions is to have “intersectional” mean when there is a shared solution.

<Glenda> Katie: suggest adding a glossary

<Chuck> AWK sounds pretty good, but there seems to be a bandwidth issue.

RESOLUTION: Jeanne/Shawn to clarify “intersectional” and think about a glossary.

<Cyborg> not hearing 90% of what being said

Design Principle 2

<corbb> Most of that discussion was about how to note actions in IRC; as long as you can hear now, you’re good.

<Glenda> Accessibility Guidelines should: “Support a measurement and conformance structure that can include guidance for a broad range of disabilities, including low vision and cognitive accessibility needs.”

<Cyborg> @corbb - no, can't hear Shawn, can only hear AWK

<Glenda> Shawn: good support, but need to discuss AWK’s question.

<Chuck> I concur. AWK can be heard, but Shawn sounds like talking in a fishtank.

<Cyborg> AWK only one heard

<Glenda> AWK: It is probably fine for Principle 2 to be “fuzzy” to measure…now that I understand it isn’t a measurable requirement.

<Cyborg> can't hear this speaker either

<Chuck> Suddenly quality improved.

<Glenda> JF: I have a concern that we are calling out 2 different disability types. Some people might feel left out. Could be misunderstood. Either list them all or remove “low vision and cognitive”.

<Glenda> Jeanne: We were asked to include this by people who had major concerns for large gaps left for these specific disabilities.

<AWK> Perhaps: "including physical, sensory, and cognitive disabilities." ?

<Zakim> MichaelC_CSUN, you wanted to say at this stage let´s call out, in future version do comprehensive list

<Glenda> Michael: About a year from now, I could see this as a refinement for the future.

<Glenda> Katie: important to have an inclusive statement.

RESOLUTION: Overall agreed on the design principle itself. But need to make the including statement more inclusive.

DESIGN PRINCIPLE 3

<bruce_bailey> it could be two sentences, instead of compound sentence

<Glenda> “Accessibility guidelines should: Be flexible enough to support the needs of people with disabilities using emerging technologies.”

<Glenda> Lauriat: Got extremely strong support.

<Glenda> AWK: I agree it is a great aspirational statement. The challenge is how do you do it. Now that I understand the difference between requirement and principle…if this is the “aspiration”…

<Glenda> Lauriat: That is why it ended up as a Principle and not a Requirement. It is aspriational. When we can, we should.

<Glenda> JF: Any thought of how responsive it could be to a timeline. Example 10 years for 2.0 to 2.1. Because tech moves quick, that is too long of a gap.

<Glenda> Lauriat: Yes. That is a requirement (timing).

<Chuck> That's great audio.

<Glenda> Mike_Elledge: I know this is aspirational…but what about compatibility with WCAG? Are you going to keep backward compatibility for WCAG 2?

<Glenda> Jeanne: This is a major update. No plan to keep backward compatibility with WCAG 2.x

<JohnRochford> +1

RESOLUTION: accepted

Design 4

<Glenda> Lauriat: Accessibility guidelines should: Follow accessibility guidance.

<Glenda> Lauriat: clarifying it to answer question. The guidelines should meet the requirements.

<Glenda> AWK: Could this be moved to Requirement since it can be measured. We did this in WCAG 2.0…we made sure the doc itself met WCAG 2.0.

<CharlesHall> the research showed that people found using WCAG to be difficult. so this was specifically in response to those insights.

<Glenda> Jeanne: Propose to leave as a design principle until we have a SIlver Conformance measurement system. Then once we have Silver measurement method, we can remove it.

<Glenda> Rachael: I don’t like it here in aspirational principles. Make it clear we are moving this to a Requirement (after we define a conformance model).

<jeanne2> ACTION: Jeanne will add a note that this will move to a Requirement once we have a Conformance Model defined.

<trackbot> Created ACTION-343 - Will add a note that this will move to a requirement once we have a conformance model defined. [on Jeanne F Spellman - due 2019-03-18].

RESOLUTION: Move (later) to requirements.

Design Principle 5

<Glenda> Accessibility guidelines should: Be written in plain language, as easy as possible to understand.

<Cyborg> remote relying on irc, mics not possible to follow

<Glenda> AWK: this is a principle we are trying to achieve. it must be understandable.

RESOLUTION: In agreement this is a good thing to have. More points to consider in how you would measure if this were a requirement, but it is a principle.

Design Principle 6 (moving to creation process for the guidelines)

<Glenda> The creation process for the guidelines should: Include people with disabilities and recognize that they are important contributors to accessibility standards and solution.

<Chuck> I'm following audio a bit better, but combining audio and notes to follow. Audio cycles between acceptable and poor. I'll live with it, I don't want local members taking away from meeting time to try and solve.

<AWK> "Include people with disabilities TO recognize THE IMPORTANCE OF THEIR CONTRIBUTIONS to accessibility standards and solution."

<Glenda> AWK: if we have a good reference to show who we are building this for (who needs to be included). Then we could just point to that reference instead of long lists in every spot.

<Glenda> Jeanne: danger of a list, is it is always incomplete, and those not specified are excluded.

<Glenda> Rachael: important to indicate representative group of diverse needs.

<Cyborg> can't hear anything

<Glenda> JakeAbma: what does “include” mean? part of working group, or just including in usability testing. We need to clearer.

<Glenda> Jeanne: context behind this statement is to address the people who felt excluded in AGWG. Problems with github for low vision and coga. This is very much about including people in every aspect of the working group processes and tools.

<Glenda> MichaelC: I think this is about the design of the guideline. Making sure people are included in the process of creation of the guidelines. We could reach out to the disability groups more.

<Zakim> MichaelC_CSUN, you wanted to clarify design of guidelines from design / eval of content

<Glenda> Lauriat: meaningful involvement in process and accomodation in tooling

<Glenda> Katie: If we can’t do this ourselves, how in the world could we expect anyone else to accomplish this?

<CharlesHall> this participation would include the period of public comment as well once a document is on the TR track

<Glenda> Shrirang: Make sure it is research based.

<Glenda> Lauriat: For this design principle itself, we didn’t specifiy how to include because we wanted it to cover everything. All facets, initial research, crafting guidelines and EVERYTHING we do to create the guidelines.

RESOLUTION: We have agreement that this is an important principle. There is room for clarification.

<Glenda> AWK: this was also true in WCAG 2.x. There are always challenges. Important that if you are having problems, ask for help so we can create accomodations. Some of what makes this work hard is the pace. Even if it is technically accessible, the pace may be too fast. We try to accomodate.

<Cyborg> someone's not muted, now i hear two

<Chuck> That's Andrew's combined with the local mike in use.

<Glenda> Cor: I want to underscore how appreciative of this principle, but in the past it has often been a PC thing to say…but often doesn’t get done. So, that is why you still hear concern.

<Cyborg> who is speaking now?

<Chuck> Katie

<Glenda> Katie: I would like this to be create the accomodation first, don’t make people come and ask first, as much as possible.

<Cyborg> who is saying this?

<JF> +1 to adding "Actively"

<Chuck> AWK: I don't know if this is too combersome for you, but it would be better if you muted when another mike becomes hot.

<Cyborg> who was that?

<Glenda> Lucy: suggest adding “actively recruit, actively review our tools and process for accessibility” getting things done needs to be the 2nd factor. The first factor is must be accessible.

<JF> @cyborg that was Luci Greco

<CharlesHall> +1 to Lucy

<Glenda> JudyBrewer: +1 to what Lucy said; setting specific goals of evaluating and addressing tends to work better than a general statement about yes lets be accessible..

<JohnRochford> +1 to Lucy's commentary

<Cyborg> +1 to the part i could hear from Lucy

<Glenda> Luci: we need to see the participation count of actively represented disabilities. Active monitoring.

<Glenda> Mike_Elledge: Do we also, when we find a11y problems in tools, can we report the bugs to those software vendors and ask to them to fix those issues.

<Chuck> Mike_Elledge: Your mike is hot, echoing with AWK's.

<Glenda> AWK: we had high hopes that github would provide all the magic that would make everything work, and make it so more people could contribute in more ways. It had some pros and cons. We need to recognize that github and pull requests may not work for everyone. Let info flow in…in more ways than just github.

<Zakim> jeanne, you wanted to discuss culture change

<Glenda> Jeanne: this is not only about the tools, this is also about a culture change. I hope things have changed. I’ve seen a lack of respect and that MUST change.

<CharlesHall> +1 to Jeanne. this builds on what Lucy said about actively recruiting – that part is not about the tools, but the culture of openness

<Glenda> Judy: Back on the tools question. When MS aquired github I passed along issues. I’m happy to reach out and see how MS is now trying to resolve some of these known issues. Encourage working on improving the culture of respect.

<Glenda> AWK: I don’t think that disrespect has ever been appropriate in the work group. When disrespectful behavior happens, the chairs must address it. There can be different levels of frustrations and sometimes people respond inappropriately, but that does not make it acceptable. We should continue to aspire to respect and I expect it.

<JF> +1 to Jake

<Chuck> +1 to Jake

<Glenda> Jake: I have a different experience. I see everyone being respected and being taken seriously. I’m wondering where it happens. I’ve never heard it or seen it. I haven’t see the disrespectful behavor. I’ve never been in a group where there is more respect that this one.

<bruce_bailey> +1 Jake, thanks

<Brooks> I had to add Lucy's question to the IRC today - that needs some change.

<Brooks> scribe: Brooks

Glenda: I want respond to what Jake said. People who don't have "official" disabilities, should remain quiet as folks who do take the time to share their experiences. We should take the time to better understand what they are describing and sharing.

MichaelC: Good points, but likely taking us away from the questions we need to deal with today.

<MichaelC_CSUN> ones we should address, but think more effectively over beers than in the meeting room

<inserted> some frank well-intentioned interchange would be great

Design Principal 7

Accessibility guidelines should have: Have global participation and feedback.

<JF> suggest change "Have" to either Encourage or Facilitate

RESOLUTION: We have agreement on this principle, with possible wording tweaks

Design Principle 8

<Cyborg> who is speaking now..?

<Cyborg> Andrew was clear

Accessibility guidelines should: Strive to be data-informed and evidence-based.

AWK: Maybe "strive" should be taken out, some people have commented

<Cyborg> seems like only mics working are Andrew and Jeanne

<MichaelC_CSUN> <bon mot for the day: requirements for the requirements vs requirements in the requirements>

Bruce: We want to be consistent in the language/tense of principles language

JF: We need to be thoughtful about how we are going to gather research data

<CharlesHall> there is a TBD idea that data and research would be linked to similar to an ‘understanding doc’

<Cyborg> is it worth what?

<Cyborg> what was the question?

Lauriat: We have some expertise in this area, but we there are opportunities to work the experts to better flesh these details out.

<bruce_bailey> i think JF english term was "present infinitive"

JF: Is it worth figuring out, as part of the principal, exactly how we are going to make these things data-informed?

Lauriat: We have different methods for different purposes.

<Zakim> MichaelC_CSUN, you wanted to say including research about PWD could go here

MichaelC: Tying in to what someone said earlier, maybe we should include research on people with disabilities. It could be this is an opportunity to do that under that principle.

<AngelaAccessForAll_> +1 to Lucy

Lucy: Data can sometimes eliminate people with disabilities, especially if they are a small number. Need to make sure that doesn't happen.

<laura> +1 to Lucy. vestibular disorders is an example

<jeanne2> +1 to Lucy

+1 to Lucy

<Chuck> +1 to Lucy.

Corbb: What if there is no evidence out there yet? How would that work? Need to be careful about how lack of evidence plays out, in terms of marginalizing people with disabilities.

<mbgower> as per my comment in the survey, https://www.w3.org/TR/WCAG21/#animation-from-interactions was exactly this situation. no data but user need

RESOLUTION: We are in agreement, with the caveat to not let data-driven process exclude minority groups of people with disabilities

<Lauriat> "no workarounds for AT flaws schould be reccommended, instead, AT should be explicitely encouraged to improve on its weak spots in a timely fashion. seriously."

Additional principles

<Lauriat> "Should we include a design principle about the ability to support automated testing when possible and provide a method for repeatable test results when manual testing is required?"

Rachael: We do we do if we have two different tests?

Lauriat: We do have a requirement that deals with multiple ways to measure, which speaks to your point.
... We don't have anything about trying to encourage automated testing when possible, but open to developing that.

Katie: I think about the automated testing, and wonder if it would reference Accessibility Conformance Testing (ACT)? I'm assuming that we are going to have a similar methodology for Silver.

Jeanne: At TPAC we worked out a process with the ACT folks for Silver.

Lucy: My concern is that we say that results should be documentable. I'd like to say that we need to more clear about documenting the process, the repeatable steps.

Lauriat: Any other Design Principles we should consider?

RESOLUTION: The Silver group will discuss a new Design Principle

Requirement 1

<Lauriat> "Multiple ways to measure: Different guidance has potential for different measurement beyond a simple true false success criterion so that more needs of people with disabilities can be included."

<Chuck> Apparently remote participation has been muted in room.

Lauriat: Comments were largely in agreement, but there were a lot of comments. We agree there needs to be clarification here, just need to determine what that is.

Mike Gower: On Additional Design Principles, if there's some way we can pull in user agent requirments, it would be really helpful. Has that been discussed?

<Chuck> We heard him on our side quite well.

<alastairc> I'm making a comment on Requirement 8 as we speak...

AWK: User agent guidance is discussed.

Jeanne: Its in the scope section, but not in great detail. Look in 3.8.

<Chuck> Probably bandwidth issue on remote side.

<CharlesHall> I understood the gist of the comment was ‘should the user agent considerations also be amongst the principles and not just the requirements?’

<Chuck> Great conversation AWK!

AWK: We will be talking more in depth on this topic later in the discussion.

Corbb: If a criterion doesn't just pass or fail, what other things might it do?

Lauriate: Here's an example. Alternate text can have a pass/fail as to whether its there. There's another facet here that is more nuanced, and that is does the alternate text provide equivalent purpose to the non-text content. The quality of that alternate text can be measured along a scale, not just pass/fail.
... We will expand upon pass/fail.

<kirkwood> very good point. “equivalent experience”

JF: We are going to have to discuss the impact of measuring conformance differently, considering the regulatory/legal implications.

<JF> @J Kirkwood - currently states "equivalent purpose" - not experience

Lauriate: Agreed.

Mike Elledge: Are the mechanisms that go beyond true/false going to be further explore?

Lauriate: Yes.

<kirkwood> law is experience, purpose is WCAG

<laura> It depends on what the other measures are.

Lauriate: We are going to consider all comments, but want to focus how to extend conformance guidance beyond simple true/false. Expert heuristics analysis is an example.
... We want to encourage paths to things like usability testing, but are not having them be a requirement for conformance, due to the expense and resource requirements.

AWK: I think this requirement is a good idea, if the discussion of conformance models went one way versus the other, I think I might have a problem.

Lauriat: I agree.

Rachael: I'm struggling with why this is a requirement and not a design principle?

Lauriat: Its not a requirement that all tests within Silver have n number of tests beyond true/false.
... If we only have Silver include the content we have in WCAG, we will have plenty of things to work on to expand testing.

Mike Elledge: This sounds like Best Practices territory, or are you thinking about something that's going to be more solid than that?

Lauriate: We do want to be more specific about how people will perform assessments, but we don't want to overly prescriptive and miss something that we haven't thought of yet.

<Chuck> I AGREE

<laura> -1 until the specifics are worked out.

Lauriate: It seems like we don't have any disagreements here, in terms of a requirement. Is there anybody that disagrees that this should be a requirement for Silver?

AWK: Part of what makes this challenging for me is that it feels a little backward. It may just be that we have language that says conformance must done using any number of approaches.

Katie: I agree that we need to be flexible here.

Jeanne: We need to flexible enough to accurately assess the user need - that's how we should write the test.

JF: Is this a pass/fail of meeting the user need?

Jeanne: Things are being built from the user need up through testing, on to the guidelines.

Lauriat: This is THE conformance model requirement.

<jeanne2> +1 to Lucy

Lucy: It's important to state that these tests need to change, if we discover that they are inadequate. As we learn more about disabilities and users, we need to be able to change the tests.

<CharlesHall> an important distinction for the intent of this 3.1 requirement is that a qualitative evaluation still has a measurable outcome that can determine a pass or fail.

Lauriat: I agree. This is part of what the next Requirement gets at.

Lucy: Here's an example of what I'm talking about. Alt text might be inappropriate because it doesn't convey meaning. One of the tests may ask what did the developer mean by providing the alt text they did?

<CharlesHall> +1 to Lucy comment that tests are not static but can and should evolve, but this may be in the governance

Katie: I'm concerned about here is that the requirement might be dependent on a particular test.

Jeanne: Its actually a many-to-many relationship.

<mbgower> many to many relationships are almost always worrying

AWK: If this is the only conformance requirement in Silver, it is likely not adequate to express our intent. We need to be able to annotate all of what we've talked about and make more clear through more complete language what the conformance piece is.

Lauriate: Would it be worth noting Andrew's comment here?

AWK: Sure.
... Any other comments on this topic?

RESOLUTION: Silver will check in with the group to make sure that additions to this requirement are incorporated.

<Chuck> adio just went to crud.

<CharlesHall> when is break over?

<Chuck> k, now muted.

<mbgower> okay

<Chuck> AWK: I have some feedback on audio for you that I'd like to share if you have 2 minutes.

<AWK> We're coming back together in a couple of minutes due to a coffee delay

<AWK> Chuck, you there?

<Chuck> yes

<AWK> go ahead

<Chuck> P.S. A "coffee delay" sounds serious!

<LuisG> scribe: LuisG

<Chuck> AWK: I'm probably going to attend Silver agenda items this afternoon.

AWK: We're back.

lauriat: We're at requirement 2

Flexible structure

<AWK> Text - Flexible structure: Create a structure for guidelines that can better meet the needs of people in unanticipated technologies and interactions.

lauriat: Got some more responses from the survey.
... we're on flexible structure...the second requirement

<Judy> [judy: FYI, ther is coffee coming, sorry for the misunderstanding before.

<Judy> [judy: FYI, there is coffee coming, sorry for the misunderstanding before.]

lauriat: I made a note to call out tests in particular
... as tech goes forward, the tests will need updated and we wanted to included it in the scope
... in the survey results we have 14 agreeing. half split with changes. similarly many comments which we will skim through as we discuss
... we wanted a requirement for maintenance to be manageable to cover unanticipated technology or modalities we hadn't considered originally
... around things like with mobile guidelines and desktop guidelines, but the lines are blurred
... there are new devices and new types of technology
... there are even things happening with web technology space and having the flexibility in the structure in order to account for that
... so we can have more recommendations of how you do things on the technical level
... technology specific methods are decoupled so it's more flexible

lucy: I want the word "organic" added to this. and that it be frequent as well as flexible. we don't need to wait another 10 years for another version. "organic" and "frequent" be added

lauriat: we had that in mind when writing it, but it was more implied than explicit...I like the idea

<CharlesHall> is ‘organic’ a term that would need to be defined in context?

katie: also emerging technologies. there are ones we know are coming and ones we don't know are coming

<Chuck> AWK: Now you need to unmute.

<mbgower> Not hearing anything

katie: AR and VR are here, we're just not in them yet

lucy: is the word "open" appropriate?

JF: That would be implied
... if it was a closed tech it wouldn't be in W3C space maybe?

<kirkwood> audio back.

JF: we don't really create guidelines for closed standards

AWK: or closed technologies?
... for example, Silverlight and Flash

katie: we want people to use these in any technology they use. we want to encourage things to be open

AWK: maybe it requires knowing more about where it goes to meet it...just reading this I'm reading structure for the guidelines..how do we measure if it can work with something we couldn't anticipate
... are you saying it's more about the lifecycle and update process for this resource

lauriat: yes
... we can roll in new technologies

AWK: I think the requirement should be around the maintenance model. it makes it more clear that it allows technologies to be brought in more rapidly

<Glenda> (i’m actually on queue as a proxy for Chris McMeeking)

lauriat: you're right. there's more than the information architecture....I like changing the focus

<jeanne2> + 1 to changing to maintenance model change

Chris: can you prove that you can do that in a tech agnostic way? that's more the process you follow in getting expert review in platforms you're not an expert in.
... you need to make sure it makes sense for experts with a specific technology

AWK: any other comments we need to look at?

lauriat: some around wording. a couple of suggestions, but nothing that needs to be addressed in this setting
... I've noted some suggestions for calling out tests, frequency, which also goes more with maintenance model

JF: Do we want to address Mike's comment?

AWK: "Expecting it to apply beyond the web" we'll likely be talking about it in further requirements

lauriat: we need to include the scope; that would be a good place for that discussoin

katie: I feel like the user is missing from this
... "multiple ways to display"

lauriat: ah, it's on the next requirement

RESOLUTION: Shift in focus of framing from structure to maintenance model so we can include process and terms for inclusion

Multiple ways to display

<AWK> Multiple ways to display: Make the guidelines available in different accessible and usable ways so the guidance can be customized by different audiences.

<CharlesHall> quick suggestion. as 3.2 moves to maintenance / governance, it should perhaps be re-ordered to last in the list

lauriat: the survey results were positive on this one

katie: include users so it's clear...the audience could be a user

<RedRoxProjects> In terms of inclusive language can we also check the use in this room - to use person/people/folks instead of GUY <3 Thanks

JohnR: "guidance can be customized by" to "guidance can be customized for"

jeanne: if you're saying it's "for" that...

JF: I can't go in and make it completely different. there's a technical capacity. maybe it's for and by; an either or

jeanne: I like both

<Chuck> I can hear her adequate

katie: I think one of the most valuable documents is the QuickRef for giving somebody that needs guidance a specific thing
... you can make a selection and share the URL and it gives them what they need

jeanne: we're looking at a model where we're going to have more guidance making that much more important

lucy: for me what comes to mind is "pick your own adventure" take the path you want
... pick and choosing, not filtering
... customizable is multiple ways to get to the same result
... you still have to rescue the princess

<Zakim> AWK, you wanted to ask if Silver expects to take on the analog to the quick ref?

<Chuck> AWK: unmute

AWK: I agree with katie about QuickRef, but it's not a publication of this WG. EO makes that.
... how does this all fit together?
... are we taking this all on? are we taking it away from EO?

<CharlesHall> no audio again

<Chuck> Anybody: Unmute

AWK: what do we need to do to meet this? what's the "guidelines" now?

jeanne: What we're invisioning is that the QuickRef becomes the frontend
... we were just working on the prototype so people could see it. the actual "TR" document would be a separate link that most people would never see

katie: the number one WCAG complaint is it being complicated..we need an easy way in but also the "TR" document

AWK: for many people the QuickRef is the frontend, and that's okay, but we didn't need to build that
... are we going to stick with that model? or are we changing that in a major or minor way?

jeanne: can we hold that for tomorrow?

AWK: sure

lauriat: We have no intention of turning down work done by others that want to help

JF: Is one of the goals to be that we're the socializers or that we're making the boring TR document which will be the definitive source?

<MichaelC_CSUN> <second bon mot: insomnia-killing TR document>

JF: if we're discussing tomorrow it's fine, but do we expect to do the prettification or focus on normative and lets others make it pretty?

jeanne: the way we do the boring work will be more easily movable into a more adaptable structure

lauriat: we're saying that if we made that one document and nobody can use it, we shouldn't call it done

lucy: i'm a little disappointed to hear the conversation going against the principle of it being accessible to begin with is better...but we're saying we're going to build the less usable one?
... why would we encourage the opposite track?

jeanne: the focus of the working group won't be the coding

lucy: the principles, etc. should be understandable first

jeanne: absolutely

Rachel: it's not just making the guidelines usable and accessible. it's making them easily adaptable to how others might use them. the difference between Word and markdown. we need to think forward on how they can be adapted
... the way it's worded sounds like it's multiple documents

<Zakim> MichaelC_CSUN, you wanted to say co-development

<Chuck> Mike's audio is in a galaxy far far away.

MichaelC: I think we need a co-development model. We shouldn't make the boring one first.

<Zakim> AWK, you wanted to say that a simply structured and clear document was what I had in mind

AWK: I agree.

<Chuck> And now no audio.

<Chuck> back

<Chuck> :-)

<Chuck> Blame me!

AWK: we want to clarify who is doing what. if we make a simple, clear, plain language document and that's going to work really well for some people, but not others
... what we know about WCAG feedback is some people think it's great and others don't; and that's okay
... that's part of it being adaptable and customizable

lauriat: instead of focusing on customizability by audiences, we have it built on how we do the guidance so it's more condusive to being in that kind of a system
... saying this is how we need to manage the guidance so it can be used in a certain end state
... if we have it focus on the writing so it can be used in multiple contexts, that goes towards what we want

AWK: It may be there is a co-deliverable to help that happen
... whether we've thought about it and it magically happens..great, but if we think about it all the time and don't meet it, that's not any better

<Chuck> * JF: Yes, for whatever reason I was able to hear that part (blaming me) quite clearly!

lauriat: sounds like the proposed focus around writing guidance is a design principle...but what we hold it to is the end state

bruce: I have a contrary view. if this group does the boring work of the normative document, that sounds like the tags and metadata instead of leaving it to Michael after the fact. we need to review the underlying structure so it can be rendered to flexible views
... if we don't pay attention to that, we're leaving it to someone else

<Zakim> bruce_bailey, you wanted to give example that TR might include tags and metadata

<Chuck> unmute

katie: we did that with the short names and meta data
... I agree

<Chuck> remove av specialist: Chuck

katie: we should take responsibility for that
... those short names were used as IDs for tools to process the data. over time things change, but they're useful for people to make the backend stuff work appropriately so we own some of that

<JF> @AWK Charter info for EO = 30 June 2020

<Chuck> The gain on that mike is not good.

brooks: I want to mention that accessibility means different things to different people. a lot of work I do is translating for the PM or the developer, or the executive.

<Rachael> +1 Brooks

<Chuck> I hear the speaking, but not the words.

brooks: acknowledging different roles need different things is important because they're not just for technicians working on the content. they're for those higher up

katie: it's because of the different roles that it was written this way

<Chuck> unmute

AWK: sounds like we're supportive that it needs to be customizable

RESOLUTION: Largely agreed, but we have notes of what to change

Technology neutral

<AWK> Technology Neutral: Guidelines are worded to apply across varied technologies and avoid being technology-specific. The intent of technology-neutral wording is to provide the opportunity to apply guidelines to current and emerging technology, even if the technical advice doesn't yet exist. Technical details are discoverable in the document structure but are not required to understand guidelines.

<jeanne2> s/neatral/neutral

lauriat: essentially we want the guidelines to not be technology specific
... also don't want to wordings that require technology specific knowledge for understanding

AWK: in the context of 2.0 is that you can use any technology and claim conformance.
... it was a challenge in some SCs that refer to markup languages...so if you're using PDF because you're not a markup language, you meet that SC
... I'm not sure what it means in the new structure. is there a fork in the road of "earlier or later" for applying a different technology

lauriat: we have thoughts on how it can work. we can bring forward guidance from WCAG into the structure...the guidelines would be at a level that isn't tech specific.
... anything that says "for markup languages" we would base it on the user need and can you get there with the technology
... if you can't, we can still have guidance that communicates the user need, but if there are no methods to meet it for a technology that guideline wouldn't be applicable
... it would highlight a gap in the technology
... with ACT, we were looking at language of page and moving it to language of environment
... what is the overall context? can you determine the language of that?
... we went through VR...from that we said if you're going into a virtual city you should be able to determine the language of that context and language of signs in that city
... I don't know of any way of doing that, then the user need isn't made. the platform doesn't have a way of communicating that

chuck: in our efforts to write this tech neutral guidance the functional conformance criteria was worded pretty good
... if you can't do it one way, you can do it another way

lucy: this is one of my favorite criteria, right now we're saying "technology agnostic" but I think it needs to be user-centric.

<Glenda> as proxy for Chris McMeeking

<Chuck> Come closer to the mike :-)

Chris: we're focusing on a problem of the technology agnostic level of the success criteria. if that's all we do, we'll eventually have disparate about what it means on different platforms
... there certainly is a need fo rthe core to be tech agnostic, but there needs to be something about what it means for a certain platform and make it easy to contribute that content

<Chuck> * AWK: Yes he sounds great.

Chris: perhaps a better way is to embrace each of them and say how it relates back to being tech agnostic

lauriat: I'm glad to hear you say that because it's almost exactly what we have planned

chris: discoverability and contributability will be critical

katie: methods will be "how this works best in a particular envirionment"

lauriat: for technology neutral, with the clarification to cover the core guidelines, but not tech specific methods..it sounds like we're mostly in agreement

<Chuck> * AWK yes

<Chuck> * AWK Last few minutes have been great.

brooks: I've said this over and over. It scares me when we take tech out of the picture to make it more timeless...but it sets up a situation where we don't make that instant communication that need to understand accessibility
... it also sets up a situation if there is no tech to deal with a specific user need what do you do? do you not present the content? do you leave it as a gap?

<Chuck> * AWK: When Mike e (???) spoke, whatever mike he used doesn't have good gain.

brooks: do you tell them to find another way to communicate that information?

<Chuck> unmute

lauriat: to pick the VR example with language of environment...having the central guidelines neutral and methods give tech specific means we can have the inverse...instead of looking at the guidelines first, we can say "these are all the guidelines VR doesn't support"

<Mike_Elledge> Mike E: Can't we include both user-centered and technology-agnostic.

<Chuck> * AWK: No worries. We know this isn't going to be perfect. It's pretty good for what it is !

lauriat: "these are the problem areas" that don't meet users functional needs

jeanne: the beauty is to make it clear and easy for vendors that creates the levels of the stack to filter and see the work that needs to be done

<Chuck> AWK: If it were perfect, nobody would go.

katie: the need of the user could be to have a 3d image vibrate, but the tech doesn't have it...maybe it would be a need a technology could fill. maybe there are other things, but not vibrating
... that will turn itself into a matrix chessboard of where things can be met and where there are gaps...and opportunities to meet that need and fill that gap

lucy: are we asking the guideline to ask for those gaps?

katie: it would end up doing that by starting with the user need
... some won't be fillable

lucy: helps us in academia figure out what we can and can't buy

brooks: where do we bring in the requirements for the user and user agent technologies? in writing normative guidance we establish a need and a way to meet that need
... if you disconnect that, who conforms?

AWK: what i'm hearing is that people want the guidelines to be technology independent, not tech specific and there are multiple ways to achieve that..but the requirements isthat it's to be achieved

lauriat: there's another aspect. even though we plan to write up methods and getting experts to write them
... having the methods we neutral, the needs can be met in multiple and new ways

JF: like the Techniques we have today

lauriat: right
... we need to adjust the wording so it's more clear it's covering the core guidance and not the methods we've been talking through
... not every thing we work on...just the core

<Chuck> good thing too!

<Chuck> * AWK: that sounds like a story

AWK: and that's how you remove the word "avoid"

RESOLUTION: agreed with some minor wording changes

Readability/Usability

<AWK> Readability/Usability: The guidelines are understandable by non-technical audience. Text and presentation are usable and understandable through the use of simple language, structure and design.

Shri: what does "usable" imply?

lauriat: we should clarify the scope.
... for the first sentence...that's specifically the core guidelines to make sure people can read it without tech specific knowledge
... for the rest it should apply to everything we produce

JF: when you say "simple language" do you mean "plain language?" some stuff isn't simple; some is nuanced. we want to be plain about it

jeanne: we keep changing whether we say simple or plain and I think that's an artifact of when we were going through a simple language phase

<kirkwood> plain

jeanne: I think that should be done by the experts in plain language

AWK: are we determining whether its usable or not

brook: what's plain often depends on the audience

lauriat: in the methods if we're talking about how to meet using ARIA and CSS, we would need terminology specific to those, but everything around it can be plain language
... reserving technical jargon when it's needed

brooks: we also need to understand the audiences. different people have different words they use

katie: we need a glossary to help provide understanding

JF: we also have to remember internationalization

lauriat: one of the prime considerations..not just for English speakers/readers, but translating into different language

<kirkwood> https://www.plainlanguage.gov/ -granted it’s US

lauriat: I think the main point is going back to working on this with the plain language experts so we know what we're signing up for

AWK: there's a plain language audit that happens at the end

lauriat: we were thinking of having the subject matter expert give it a shot and then working with a plain language expert to make sure you're not losing the message
... it has to start at the concept of the problem to solve

RESOLUTION: Language needs to be tweaked to clarify scope and working with experts in plain language for how we would measure success

Regulatory Environment

<AWK> Regulatory Environment: The Guidelines provide broad support, including: * structure and content that facilitates adoption into law, regulation, or policy, and * clear intent and transparency as to purpose and goals, to assist when there are questions or controversy.

jeanne: this was drafted by a lawyer

lauriat: we had a lot of conversations about this one. the main point is having a requirement that states we want to continue supporting the regulatory environment
... we're focusing on clarify of intent, transparency, and making it so the guidelines can help when there is controversy about whether "something" has been done
... maybe it would help to start with the survey "disagrees"
... is it with wording or it being a requirement?

MichaelG: this seems too broad and too limited
... if you're going to support law, regulation policy...there are possible contradictions like doing regular updates
... that's going to be need to be though about...are you going to have a release and different versions that exist forever for reference?
... it seems more aspirational than a requirement...I either want a lot more detail or ...more like a guideline

lauriat: there's adoption into law, regulation, policy...from that standpoint, the core guidelines would provide that
... and the updates of core guidelines would happen less than methods, etc.
... the other side is the more that we update them, the more helpful it is to assist when there are questions
... so we can give updates guidance around technology

MichaelG: right now the techniques aren't normative. that doesn't detract from the guideline from the standards perspective
... it's kind of status quo

jeanne: in many ways yes
... we wrote this because it kept getting reported that Silver wouldn't work in a regulatory environment
... we kept saying that it was at the core of what we're doing so we needed it in the requirements

AWK: I fully agree that we want it to work in a regulatory environment, but we need to nail down the attributes that need to be a certain way and have that specified in the requirements
... if it's that individual criteria needs to be measureable in certain ways, it should be documented
... I think we need more detail

lauriat: what you're describing is the how...the requirements is the "what" we will need to determine the "how" but not in the requirements
... once we agree that we need to support the regulatory environment, then we can figure out the "how"

JF: we agree that supporting it is one of our goals...but I don't see measurability or testability in there which is important for supporting a regulatory environment
... it seems vague like "we want world peace"
... without defining how, then what are we chasing?

<alastairc> As someone painfully aware of conflicting goals being promised and then unable to be achieved (not in a WCAG context), we should outline how that balances with the other requirements.

lauriat: we're specifically saying law and policy and usefulness when there is controversy

<AWK> ack

<AWK> AWK

lauriat: we need to figure out the how...there are two sides of the regulatory environment and we're addressing them

katie: we realized we needed a language changes from WCAG 1.0 to 2.0 and people are used to our current language...people's jobs is to clarify..and like any organization, you build FAQs out of questions that are coming in
... you have answers for clarification that help the organizations for their laws it'll be different, but provide a starting point for how to answer it within their own regulatory environment
... as clarifications come up, let's have resources that come up to help with the need for clarifications

lauriat: but I don't want to tie us to a speicific method of doing it in a requirement

<Zakim> JF, you wanted to suggest adding methodology: structure, content, and methodology that facilitates

JF: we can have it broad enough, but giving us something measurable other than supporting
... we need that methodology so there is a path for determining conformance

katie: we don't have that in a standard...you talk about the outcome, not how to do it

brooks: if you're looking at setting it up for success...you look at who is compelled to do what
... you need accountability and responsibility..some onus is on the user to do what's necessary
... without having to be too detailed I think there's some general principles we can address for how to break it up about who is compelled to do what
... they want to know who isn't doing what they should do?

katie: it's their job to define it...we have to make it work for those environments...they assign who does what
... saying our language will facilitate it...we're automatically in that space.
... we will need actual professionals to check that over time
... it's not our job to assign the roles; we can have content for the roles that's friendly enough to work in those environments

lauriat: for that adoption to happen Silver needs to be published first. we've been trying to keep in mind involvement with stakeholders so that we can make sure they have a say and can give us feedback so we can course correct rather than revising later

MikeE: are you thinking bringing methodology in is too close to the "how?" even though it's not strictly delineated by a technique, I think the implementation aspect is really important

lauriat: I don't think it would be too detailed, but I'm going to check with John offline
... I know we have broad agrement that yes we need to support the regulatory environment..but where are we in terms of level of specificity for this requirement for silver?

AWK: I think we need to know from policy/regulators what they're looking for. maybe the focus isn't something we have as a requirement

<Chuck> I like JF's suggestion of putting in the word "methodology". Goal is defined here, details come elsewhere.

lauriat: this makes it explicit that it's a goal of silver
... this gives us a framework to work with regulators to identify that might better support them

AWK: we should find out if they want that or not
... I suspect regulators just want something that's done and clear that they can point to rather than having a project

<bruce_bailey> Access Board needs differ than court

AWK: if something is really close, then sure...but one thing we want is to separate ourselves from individual policy engagement so the document is ready to reference
... what makes it read to reference needs to be reflected in the requirements

katie: this just says we're going to make it appropriate for policy makes..so it'll help them

AWK: how do we know we've succeeded with this?

katie: questions get turned into a repository of clarifications

jeanne: we wouldn't have that for CR

lauriat: we can help that with some usability testing while developing aspects...we can get feedback of how we're doing

katie: that FAQ doesn't need to be normative
... we know those questions will come up from people that are reviewing from the outside

bruce: the first bullet would be what the Access Board needs...stable language for a version
... it also comes up in court settings
... someone was saying a judge wants to know why some things are A, AA, or AAA?

jeanne: that came out of research where we interviewed lawyers..it was a common theme. they need the language clear enough for a judge
... and they need to know why it is the level it is
... the regulators asked for plain language so they could explain it internationally
... it wasn't just for translation, the Canadian regulators needed to be able to understand the SCs... and they can't

AWK: that's a specific call out within requirement 5..."for audiences...including..."

<kirkwood> +1 to legal understanding need

<Chuck> did somebody mention peanut butter? <stomach growls>

lauriat: we're solid on the intent...but the wording and what gets included in the requirement
... I have JF's suggestion as well as including the audience that would be affected

brooks: and who would be required to do what
... I think it's hard to expect people using this in law to handle complex situations we're having a problem with

lauriat: I don't think we can include that guidance of who needs to do what

<Chuck> * Whoever is speaking is hard to hear.

brooks: "here are the players" "here are the pieces" for a good UX

lauriat: absolutely and that's requirement 8

AWK: and how do we handle the rest?

lauriat: if folks could fill out the surveys that would be a good starting point
... I propose we compare our notes, get everything in one place, and check with the chairs about who to include for the remaining requirements
... so we can put it out for a call for consensus

AWK: the discussoin with everyone is helpful
... if there are 2+ things left. maybe we should just put it on a Tuesday agenda

lauriat: sounds good

<alastairc> Is that an hour & 10 min?

RESOLUTION: Agreed on the main purpose, but have to work through some solid discussions

Summary of Action Items

[NEW] ACTION: Jeanne will add a note that this will move to a Requirement once we have a Conformance Model defined.
 

Summary of Resolutions

  1. Jeanne/Shawn to clarify “intersectional” and think about a glossary.
  2. Overall agreed on the design principle itself. But need to make the including statement more inclusive.
  3. accepted
  4. Move (later) to requirements.
  5. In agreement this is a good thing to have. More points to consider in how you would measure if this were a requirement, but it is a principle.
  6. We have agreement that this is an important principle. There is room for clarification.
  7. We have agreement on this principle, with possible wording tweaks
  8. We are in agreement, with the caveat to not let data-driven process exclude minority groups of people with disabilities
  9. The Silver group will discuss a new Design Principle
  10. Silver will check in with the group to make sure that additions to this requirement are incorporated.
  11. Shift in focus of framing from structure to maintenance model so we can include process and terms for inclusion
  12. Largely agreed, but we have notes of what to change
  13. agreed with some minor wording changes
  14. Language needs to be tweaked to clarify scope and working with experts in plain language for how we would measure success
  15. Agreed on the main purpose, but have to work through some solid discussions
[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2019/03/11 20:38:46 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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)

FAILED: s/we aren't starting until half past the hour. //
Succeeded: s/two of us (me and Andrew) already on WebEx but no sound yet...//
Succeeded: s/Foliot/JF/
Succeeded: s/ specified feel excluded/ specified are excluded/
Succeeded: s/to what Lucy said/to what Lucy said; setting specific goals of evaluating and addressing tends to work better than a general statement about yes lets be accessible./
Succeeded: i/TOPIC: Design Principal 7/some frank well-intentioned interchange would be great
Succeeded: s/process minority groups/process exclude minority groups/
Succeeded: s/rachelle/Rachel/
Succeeded: s/Rachael/Rachael/
Succeeded: s/neatral/neutral/
FAILED: s/neatral/neutral/
Succeeded: s/sound/sounds/
Found embedded ScribeOptions:  -final

*** RESTARTING DUE TO EMBEDDED OPTIONS ***

FAILED: s/we aren't starting until half past the hour. //
FAILED: s/neatral/neutral/

WARNING: Replacing previous Present list. (Old list: AWK, Cyborg, Chuck, Rachael, jeanne2, Lauriat, JF, corbb, JohnRochford, Laura, Brooks, Katie_Haritos-Shea, bruce_bailey, JakeAbma, MarcJohlic, Glenda, Makoto, shari, MichaelC_CSUN, mbgower, Kathy, CharlesHall, kirkwood, Roy, alastairc, LuisG)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ AWK, Cyborg, Chuck, Rachael, jeanne, Lauriat, JF, corbb, JohnRochford, Laura, Brooks, Katie_Haritos-Shea, bruce_bailey, JakeAbma, MarcJohlic, Glenda, Makoto, shari

Present: AWK Cyborg Chuck Rachael jeanne Lauriat JF corbb JohnRochford Laura Brooks Katie_Haritos-Shea bruce_bailey JakeAbma MarcJohlic Glenda Makoto shari AngelaAccessForAll RedRoxProjects
Found Scribe: Brooks
Inferring ScribeNick: Brooks
Found Scribe: LuisG
Inferring ScribeNick: LuisG
Scribes: Brooks, LuisG
ScribeNicks: Brooks, LuisG
Agenda: https://www.w3.org/WAI/GL/wiki/Meetings/CSUN_2019#Monday_11_March_2019
Found Date: 11 Mar 2019
People with action items: jeanne

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]