Minutes of the Silver meeting of 13 April 2018

Formatted version of the minutes:

*https://www.w3.org/2018/04/13-silver-minutes.html
<https://www.w3.org/2018/04/13-silver-minutes.html>*

Text version of the minutes:

   [1]W3C

      [1] http://www.w3.org/

                    Silver Task Force Teleconference

13 Apr 2018

Attendees

   Present
          MichaelC, kirkwood, JaEunJemmaKu

   Regrets

   Chair
          SV_MEETING_CHAIR

   Scribe
          Luis Garcia

Contents

     * [2]Topics
     * [3]Summary of Action Items
     * [4]Summary of Resolutions
     __________________________________________________________

   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_>
   [5]https://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html

      [5] 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_>
   [6]https://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html

      [6] 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

   <Lauriat> trackbot, end meeting

   <Jemma_> scribe: Luis Garcia

Summary of Action Items

Summary of Resolutions

   [End of minutes]