Silver Task Force Teleconference -- 13 Apr 2018

Shawn: Usability, we have 5 recommendations.

<Lauriat> First one: Take existing WCAG 2.1 guidance and re-write it in plain language using editors with simple language or plain language experience. The existing success criteria may need to be updated, but most of WCAG 2.1 guidance is still valid. It needs more clarity, ease of reading and ease of translation.

<Lauriat> 2. Organize the data in small snippets that can be coded and categorized so they can be assembled dynamically to meet the needs of the person looking for information.

<Lauriat> 3. Create a comprehensive view for W3C Technical Report purposes, and for those who need the view the total document.

<Lauriat> 4. Create entry points and view by role, by problem, by disability, and by platform.

S: Not completely convinced of that conclusion, but more we need solution of different roles for different goals to get the information they need. Maybe different entry points or something that better considers these transition points.
... rather than focusing on entry points and views, something that addresses needs of people with different roles or different goals when they go to guidelines. Problem was ramp up for new people. How people discover what they need to know. Sometimes "how to know more" sometimes "how to fix this thing"
... not only entry points. That's just part of it. View were there as well. Haven't done enough prototyping to know we need more entry points and views for different roles.

<Lauriat> 4. Create a solution that addresses the needs of people to find information by role, problem, by disability, and by platform. How can people discover what they need to know.

<Lauriat> 5. Design a home page that is oriented toward helping beginners that is separate from the W3C Technical Report. Include shortcuts for expert users who know what they want (e.g a code sample for an accessible tab panel)

S: anything to that chat about before moving to conformance?

Jeanne: Anything that is missing?

Shawn: This is specifically in the usability bucket. Maybe just the various "how might we" ideas. Probably more stuff to add later, but for conclusions of "we did this design sprint and have these recommendations" this addresses a lot of it.
... moving on to conformance

<Lauriat> 6. Change the conformance structure and style guides from “testability” to “measureability” so that guidance can be included that is not conducive to a pass/fail test. Pass/ fail tests can be included, but they are not the only way to measure conformance.

<Lauriat> 7. Develop scorecard or rubric measures for testing task accomplishment, instead of technical page conformance.

Shawn: These two investigated in one prototype, so kind of grouped together.

Charles: It's a public document final report. Should we be sensitive of language "change conformance structure" to "suggest" or "design a conformance structure"

<Lauriat> 8. Develop a point and ranking system that will allow more nuanced measurement of the content or product: e.g. a bronze, silver, gold, platinum rating where the bronze rating represents the minimal conformance (roughly equivalent to meeting WCAG 2 AA), and increasing ranks include inclusive design principles, task-based assessment, and user testing.

<Lauriat> 9. Include a measure for “substantially meets” so people are not excessively penalized for bugs.

Shawn: This is kind of related to pass/fail test. But more on the complete page/complete journey. If you go through and there are any failures at all you don't conform to WCAG, but if you have 2 bugs that don't block people from accomplishing their needs, it should have a different measure than "you don't conform"

Jennison: Is it the measure? Is that the piece of this recommendation to maybe tweak?

<kelsey> Is there a way we can more clearly identify what a show stopper would be for full conformance of an experience?

Shawn: Some of the recommendation. first one in conformance tries to offer a way to do that.
... In the prototype it was more a gradient of how something worked. Still had absolutely minimum, but still helpful for identifying...you might have app where everything is below the failure line or everything is above, but some use cases are close to the failure line. Maybe unecessarily complicated but people can still complete tasks.

<Lauriat> 9 (reworded): Include a definition and concept for “substantially meets” so people are not excessively penalized for bugs that may not have a large impact on the experience of people with disabilities.

Shawn: technically meets minimum bar, but could use improvement. "This application substantially meets. Here are some things you could do to improve."

Jemma: When you look at conformance requirementsfull pages and complete processes. I think you meant complete process when you said "journey." So you're trying to cover both parts of conformance?

Shawn: Yeah

Jemma: Need more elaboration. These two already cover the scope of conformance.

Shawn: I read as inherently including those two, but rewording as not so black/white pass/fail
... It's going to be ambiguous as to what it means until we make the definition.

<Lauriat> 10. Remove “accessibility supported” as an author responsibility and provide guidance to authoring tools, browsers and assistive technology developers of the expected behaviors of their products.

Shawn: Anything missing from conformance?

Charles: We should have mechanism that follows that scoring each time there is an update.
... Maybe more appropriate in maintenance.
... But that might be more about guidelines than sites conforming to guideliens.

Shawn: Maintenance will only succeed if can bring everyone along with updated versions.
... Ties in with first under maintenance. Let's move on to that.

<Lauriat> 11. Develop a core of rarely-changing requirements (normative) with modules of platform oriented advice, examples, tests, and support materials that can be updated as technology changes.

Shawn: Kind of addressing what you're bringing up Charles. Difficulty is developing core of rarely changing requirements could be hard.
... More bringing up interaction requirements. If there is info conveyed through video, coming up with guidance of what needs accounting for which is completely indepednant of technology hardware, etc. nd reccomndations for the technical level and that you're publishing a video in a webpage or looking at it on some other device that's not using same tech. Being able to measure conformance for each independently and considering the environment.

Charles: One of the things discussed priorir and during sprint. Conformance claim is only at a point in time.
... authors need to reevaluate.
... somehow pass/fail change to a score would still be dependent on a point in time

<Jemma_> Understanding Conformance Claims It is not required to make any conformance claim in order to conform. If one does make a claim, however, the rules must be followed. Sometimes, one may want to make a claim for just the content that was added after a certain date. Or, one may want to claim WCAG 1.0 conformance for content up to a date and WCAG 2.0 for content that was created or modified after that date. There are no prohibitions in WCAG 2.0 to any of these [CUT]

Kelsey: Site might be accessible at launch, but then after no one maintains it.

<Jemma_> https://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html

Kelsey: If they're not evaluating it as they should be

Shawn: Not sure if that's in scope
... seems more like having people do their homework. Or does the conformance model need to be revisited based on that?

Kelsey: Think just based on conformance claims, but not sure what item that would be.

Charles: I'm trying to find point of reference in other documents.

<Lauriat> 12. Develop a method for accessibility experts to contribute new design patterns, codes and tests where the experts vote material up and down without waiting for working group approval.

Shawn: This one is a little specific in implementation, but core recommendation is sound. Let those that know decide so that we can incorporate technology changes without having to go through whole W3C process.
... some of this in WCAG. Recommendations trying to be tech agnostic and supplemental notes that refer to HTML5/ARIA 1.0, here is how you build a thing.

Charles: Current guidelines and process allow comments on working draft, but there is no standard method or place for public contribution outside of comment period.

Shawn: There are obscure avenues where people can, but hard to find.
... adding note to self to reword away from specificity.
... "have experts vote material up and down" is too specific
... the core goal I very much agreement. Those in-the-know about tech can determine what we're recommending for that tech
... blatantly commenting Luis's exceptional scribing

<Lauriat> 13. Change the working group process to include Community Group participation.

er...copying...not commenting :p

Shawn: This is about creation of content. A lot of ground to cover, we need to move fast and consistently.

<Lauriat> 14. Create a better interface to specification development tools (e.g. Github) so that people with disabilities can more easily participate in spec development.

Shawn: May be a recommendation to others, not W3C people. Here is something we need to succeed.

Charles: We're not proposing solution. Making recommendation that we need solution
... worth mentioning that there are multiple ways to get there; APIs to extend GitHub or have GitHub make their product more accessible
... without proposing solution maybe it's not "Create better interface" maybe "find a better one"

<Lauriat> 14. Improve access to specification development tools (e.g. Github) so that people with disabilities can more easily participate in spec development, whether through new or modified tooling.

Michael: Related to this, it's known to the W3C team, we can request features from GitHub. It's on radar of project management lead. Good to see thoughts happen here, we should coordinate and not duplicate effort.

shawn: comment to self: note existing efforts so no one builds a new Ui without consulting those already investigating

<Lauriat> 15. Develop specification content a small amount of guidance at a time, and fully develop the content before including it in the spec. Keep a public schedule when issues will be worked on, so the public can contribute in a timely manner.

<Lauriat> 16. Keep a changelog of all changes to the spec so it is easy for reviewers to find the changes.

Shawn: This may just be a discoverability change instead of a practice change. Fairly certain WCAg does this now.

Charles: It does, but the scale will change if we're changing the basic outline structure in how we write criteria. Individual line may be deprecated and not an entire criteria.

Shawn: Can we go back to conformance declaration as kind of snapshot of time item.
... Want to talk through that.

Charles: My thought is that based on conformance survey results, one of the things that came out was that conformance claims are contextual to a specific release.
... If we're going to say that "this site is 90% vs pass/fails" we still have to somehow solve problem of when measurement was made.

Shawn: Reminds of forms in elevators "Last inspected on this date"

Charles: Or copyright statements.

<kelsey> I like the elevator analogy

Shawn: Similar..VPATs have product but points to that point in time. As of this date, this is the state of 508 compliance for this product.
... this does fit in conformance better than in maintenance. More of a modification to declaration of conformance.

Charles: sites aren't static so claims can't be static

<Lauriat> 11. Develop a method of claiming conformance that is more fluid to accommodate dynamic or more regularly updated content.

<Jemma_> https://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html

Jemma: These are listing all the details. Is it more flexible? Does it need to be more detailed?
... This tech HTML, etc. don't need to write that.
... you can add some flexibility
... in terms of claiming conformance as content changes

Shawn: While it allows flexibility based on tech, etc. "Fluid" isn't the word I'd use to describe that

Jemma: Yeah, what do we mean by more "fluid?"

Shawn: First part of developing that claim of conformance is to define what "more fluid" means. Can't make infinitely flexible.

Jemma: As well as "substantially meets"
... what is our concept of fluid/flexible

Shawn: If something updates regularly but different kinds of content. News site has a poll, or video, or flat article. Maybe interactive?
... idea of having to rewrite conformance claim every time it's updated is a heavy process

Jemma: A11y for video vs other content will be different

Jennison: Should keep sidebook of terms and things we need to spend time defining.

Jemma: Conformance claim is optional

Shawn: But something people ask for
... especially as someone that works on apps, people ask for it. And apps change all the time, so updating that conformance statement can be heavy based on my experience on docs/drive. Some release weekly, etc.

Jennison: We're on three times a week, three times a day cycle

Shawn: Fairly common now. Knowing when to update conformance statements. Having something more fluid but still accurate would be fantastic
... nobody said it'd be easy.

Kelsey: Would we need to identify a timeframe. Right now based on hiring auditors, maybe quarterly basis? Seems like not very specific parameters.

Shawn: Don't want to specify timeframe. Places work wildly differently. Some every day, some every 3 years, etc.
... maybe more of a something defined as recommendation for part of process as opposed to part of a timeline
... When you publish something "substantially new" you should update this part of your conformance statement.
... maybe put together set of templates that help with conformance statement
... only a couple of minutes left. Anything else we're missing. Usability or maintenance

Dont have time for last agenda items. We got back simplified language experiment. He reworked video doc from table 4 rewording things to "simple" language.

scribe: kind of kickstarting experiment. Looking how we can do this for current WCAG 2.1 as noted in first recommendation. This is a starting point. Added in Google Drive, but waiting on what he's comfortable with before sharing.
... we have start of project plan coming together, but it looks like others have looked at it.

pick up on tuesday by finalizing the report. maybe doing most of that offline with comments. Will make sure Jeanne sees additions and notes. then we can move onto plain language experiment and project plan

Jemma: Your'e going to distribute to where?

Shawn: report to larger audiences - general working group and participants in the design sprint. as well as people in community group and ideally anyone following along

I assume you are going to wrap up the notes and stuff?

I don't know how to do that yet

<Lauriat> trackbot, end meeting

<Jemma_> scribe: Luis Garcia

- DRAFT -

Silver Task Force Teleconference

13 Apr 2018

Attendees

Contents

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output