W3C home > Mailing lists > Public > public-silver@w3.org > March 2018

Minutes of 30 March SIlver Meeting

From: Jeanne Spellman <jspellman@spellmanconsulting.com>
Date: Fri, 30 Mar 2018 08:23:17 -0700
To: Silver Task Force <public-silver@w3.org>
Message-ID: <46e7ff76-76e5-9b5e-ffde-99451b260fa1@spellmanconsulting.com>
Formatted version of minutes:

Text version of minutes:


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

                                - DRAFT -

                     Silver Task Force Teleconference

30 Mar 2018


           chaals, Charles, Jeanne, JohnM, Imelda, Kelsey, Luis





      * [2]Topics
          1. [3]Moving the meeting time (initial discussion)
          2. [4]Categorizing ideas from Table 5
          3. [5]Prototype strategy
          4. [6]Information architecture
          5. [7]Prototype design
      * [8]Summary of Action Items
      * [9]Summary of Resolutions

    <scribe> scribe: chaals

Moving the meeting time (initial discussion)

    <jeanne> 1 pref for moving Tues. ! for Friday, lots of people
    can make it work.

Categorizing ideas from Table 5

    JS: It's in the phase 3 folder, and there are results by


      [10] https://docs.google.com/document/d/1XDOmjQkMRqQ0XKiKYA-mDAuA40oHtaXNl1H0NXLcV80/edit?usp=sharing

    [11]results for table 5

      [11] https://docs.google.com/document/d/1XDOmjQkMRqQ0XKiKYA-mDAuA40oHtaXNl1H0NXLcV80/edit?usp=sharing

    JS: The group worked on strictly testable but we didn't find
    their output for that, and on "difficult to get started".
    ... today I would like to start a new document - the report on
    the design sprint.
    ... Thought to take the problem statements, and then merge in
    the outputs of each group that worked on that statement. And
    then try to shake it into clarity.
    ... Without losing ideas, I hope.

    CH: Not sure why we would extract this a different way. I
    started a document that is nearly complete for table 4 - might
    be an interesting comparison.


      [12] https://docs.google.com/document/d/1zTij1pH9NumEmMJoTFlsnpkUHpM6SmP852jmkNDjAd0/edit?usp=sharing

    CH: started to follow the outline - who was there, what problem
    statements were addressed. Then think we should have an
    executive summary.
    ... So I tried to cull out major themes, and will continue to
    edit that. Then took the literal transcriptions from the
    sprint, and have notes on what each sprint aimed at and its

    JS: We don't need an overall summary for all 5 tables?

    CH: Right. If we have summaries from each table, we can just
    put them all in a single document.
    ... I have some transcription still to do, and then to flesh
    out the executive summary, generate a report of the sprint in
    its entirety.

    JS: Better to do this by individual tables?

    [CMN thinks it is good for each table to try and put their
    stuff into a shape that can be read, and then hold discussions]

    Imelda final report form would be best for me

    AA: Do we have people from each table to represent the work?

    Imelda I have a question regarding table 3. I haven't heard
    from Jan who was going to send notes.

    <Luis_Garcia> Imelda is talking now

    JS: OK, so let's change the plans.
    ... Started thinking about how to get the work done for the
    next few months.

Prototype strategy

    JS: Would like feedback...
    ... Saw 4 things we need to get started, and work in parallel
    because they interact.
    ... 1. Get the plain language of WCAG 2.1 started. It's a big
    job so need to get it rolling.
    ... 2. Homepage design - lowest priority but the most
    contentious, so we need to start.
    ... 3. The prototype design - this is the real piece of work
    that we need to do.
    ... 4. working on the design and information architecture for
    development and maintenance
    ... tooling choices, etc.

    Kelsey: Why would the information architecture use e.g. JSON

    JS: We have traditionally worked on "flat" documents. But the
    prototypes and a lot of the ideas have been about starting from
    a collection of small atomic peices of data that we can mix and
    ... e.g. pick the things relevant to the task you are doing, or
    the technology you are using...
    ... this makes it easier to give people the kind of information
    they are looking for, rather than asking them to hunt through a
    large document for it.
    ... there are a lot of ways to do this...

    CH: Fine on having a location to start this work - a repo or
    whatever. I think what we need is to create a glossary of terms
    that advises our starting point so people can contribute.
    ... A glossary is something we want to avoid in final
    documentation, but we need a common understanding of tags we
    use to do the work.

    JS: Is that another concurrent project, or does it precede

    CH: It is probably concurrent and simultaneous.
    ... Naming things is hard so we need to figure out how we are
    going to do it.
    ... E.g. we need to have a sense of common names for
    disabilities. Does "Design Pattern" mean "how to do it" or
    "what it looks like"?

    <jeanne> chaals: I agree term design needs to happen

    <jeanne> ... I also think we need a shared single document view
    that has everything that for those that need to see everything.

    CMN: It would be helpful to have a single-document view
    available, so people *can* have a sense of everything at once,
    even though it isn't the way most people will actually use the

    <Charles> perhaps a list of known knows and known unknowns

    CH: We still have to constrain the information to match the
    scope. Don't want to spend a lot of time organising user agent
    terminology if we are not going to need much.

    CMN: Agree. work on terminology as we go, to match what we
    need, and be aware of when we need to shake down what we have
    and try to make better sense of it again.

    Kelsey: How do we make sure that this doesn't just get ossified
    after we have launched it.

    JS: One of the key marching orders was to make sure that this
    is readily maintainable - e.g. a biennial update should be

    Kelsey: Nice. Developing a glossary of terms can be a good
    chance for user research to idenntify what the terms in use
    are, and what people mean by them.

    CH: SO we need to determine where this lives - tools/repo - so
    we can organically work on the problem. I don't know that we
    have answers to all the questions yet but we need to get them
    all on the table so we can contribute to answers.


    Kelsey: Would that be for the silver TF only, or for other WGs?

    JS: Would be easiest to open a silver TF repository on github -
    not combined a priori with existing WCAG
    ... we could start small pieces.

    <Charles> There are already 574 repositories in W3 GitHub:

      [13] https://github.com/w3c

    JS: Was thinking about getting the plain language started.
    ... We hae 5 people interested in being editors to work on
    converting existing WCAG content to plain language.
    ... So as we develop, we have some concrete information to
    populate it, that we can use for testing.

    <Charles> So then the first order of business is creating a
    style guide or set of rules for simple language.

    JS: If we take a small section of WCAG and put people on that,
    we could get an idea of what it will take to cover the whole of
    WCAG - at the moment we don't have a sense of how big a work
    item that is.
    ... Another piece, thinking of scope, is that we aimed for a
    first version of silver that only covers what WCAG already has.
    But MichaelC believes there is a lot of expectation about what
    might be added, and we should consider an extra year and bring
    in some reasonable amount of new material.
    ... I feel confident we could make the current stuff in by 2020
    and do not want to work on getting new material in over this
    summer but it is something to think about.

    CH: There is a lot of work to do - we need to figure out how to
    scope the project. So we need to have a framework or styleguide
    for simple language and get some people working on it.

    Kelsey: Great idea...

    JS: So we should not look at plain language and should look at
    simple language?

    CH: That was because "Plain Language" is a term of art that has
    specific meaning to some people.
    ... related to secondary education level of people. "Simle
    language" just means what it says, so we chose it to avoid
    getting into arguments over what it means

    JS: So we need people to work on this.

    who: Do you know what the ISO standard actually says?

    JS: No, I don't. We need to have people look at this critically
    and see if the ISO thing will work for us. Sounds like a job
    for John Rochford and John Kirkwood. [and chaals - ed's note]

    who: If the ISO standard works, is that a good thing or not?

    CMN: An ISO standard that is useful would be great - the major
    issue with ISO is when their documents are really expensive. If
    it is not helpful, then we work around the unhelpful bits

    <scribe> ACTION: JS to check what it costs to use the ISO
    standard on Plain Language

    <trackbot> Created ACTION-163 - Check what it costs to use the
    iso standard on plain language [on Jeanne F Spellman - due

    <scribe> ACTION: JS to Talk to people who know about whether
    the Plain Language standard is suitable.

    <trackbot> Created ACTION-164 - Talk to people who know about
    whether the plain language standard is suitable. [on Jeanne F
    Spellman - due 2018-04-06].

    CH: Think we should look at the ISO standard, the education org
    (IMS ?), the US Federal Govt. advice on how to do this.
    ... Should try to avoid being in conflict with the US federal
    government work.

    JS: We have to remember we work for a global audience, most of
    whom are outside the US.

    CH: Sure.

    Kelsey: Regarding ISO standard, can see how it might be useful.
    Wondering if there is a risk of getting more confusion than
    benefit from trying to work to them.

    JS: We should get some named people working on this soon - in a
    ffew days. We don't want to reinvent the wheel - but nor should
    we spend too much effort twisting ourselves to meet a standard
    that isn't quite right for us.

    [Chaals, Kelsey are interested, with caveats]

    JS: This seems to be an underpinning for everything, so we need
    to get it going quickly.

    LG: I am happy to help out as well, but am not confident that I
    am *the* expert.

    JS: I am hoping you will work on getting the prototyping

    LG: Sure

    JS: We will need to divide the work amongst people to get
    there, so it will help if people figure out what bits of the
    work they want to help drive along and coordinate.
    ... people tend to work better on things they are interested
    in, so bear that in mind.

    <Charles> Table 4 prototype thus far: CodePen:

      [14] https://codepen.io/hallmedia/full/zWpoEd/

    JS: Would be good to have something we can show people in May
    as a preview of what it might look like, with some real content
    to play with.

    CH: This is a document outline using a single scenario - the
    goal was to figure out if the outline was reaonable.
    ... used a scenario of a person who cannot hear the audio in a
    video - e.g. a training video.
    ... we tried to progressively provide information, so people
    could go as far into it as they want. A simple statement of the
    problem at the beginning without saying *who* it affects. Next
    level is what is the goal to solve the problem. Deeper in, who
    does it impact and how, then ways to solve the problem, and
    those get into implementation techniques, and then testing
    methods - how do you determine if the problem
    ... was solved, not just whether the implementation recipe was
    ... Too much testing now doesn't check if the concrete problem
    for users was solved.
    ... This is as far as we got in the design sprint. Feel free to
    kick it around and work out how to move it on.

    JS: Don't think we are ready to put it in Github yet. But in
    Codepen is nice.
    ... many of these sections would be stored separately so they
    can be reused in different ways.
    ... one of the table 2 things that are not yet transcribed is
    dealing with "accessibility supported".
    ... We took a similar take, from the viewpoint of a
    sccreenreader developer - how to handle tables properly?
    ... We came up with a very similar pattern, which I think is
    ... We are on a good track here, we should start experimenting.
    Ideally we would spend summer doing user testing on prototypes,
    while we have people working on getting simple language content
    in there.
    ... And we need to start the discussion on homepage of what
    Silver will be.

    CH: Agree there are a lot of stakeholders who will have
    differing opinions. But can we say something other than
    homepage? People don't land on homepages...

    <Kelsey> So it would be the new version of this homepage?

      [15] https://www.w3.org/TR/WCAG20/

    CH: they land on an understanding page, or somewhere else
    within the document, from a bookmark or a search or citation.
    ... don't think the homepage will get as much traffic as the
    content pieces inside.
    ... So what is the information architecture of the content
    overall so people an find their way from inside out.

    JS: Indeed. But there is still a need to *have* a landing page,
    and some people will need or want to work on that.

    MC: so by "homepage" you mean "the formal silver document" on

    JS: No, although we need that too.

    MC: Normative content needs to be controlled in that space. But
    I find that not ideal for many real use scenarios. We didn't do
    much creative with undestanding in WCAG 2 having moved it inot
    a space where we could...

    [sounds of agreement]

    JS: To clarify - we cannot overwrite

      [16] https://www.w3.org/TR/WCAG20

    <Charles> the ISO style guide for how to write standards using
    “plain language”:

      [17] https://www.iso.org/files/live/sites/isoorg/files/developing_standards/docs/en/how-to-write-standards.pdf

    JS: We need at least a rough prototype for FPWD by September...

    MC: Ask EO for pointers to the work they have written. THey
    have a big task list already, so do not expect a lot off input
    from them within 6 months. Start coordinating with them now so
    they can plan to do review and give feedback.

    <Luis_Garcia> We also can't hear Jeanne

Information architecture

    JS: I have notes to follow up with people who were interested
    in creating an interface to help people file issues and follow
    them more easily
    ... (Github is not very accessible to some users)
    ... have a list of people in W3C to talk to about possible
    structures that we can use within W3C requirements.

Prototype design

    JS: Need to organise user testing, have TF prioritise which
    prototypes to try, and get some developers and designers to
    help us work with this.

    CH: One thing to consider early is the number of prototypes. We
    may end up with overlapping prototypes, and if we work out
    which ones we want to move forward we can address several

    JS: Should we talk about that before we have the final report

    CMN: There is a lot of value in encouraging people to prototype
    something, and show it, so we can see what good bits we want to
    keep, as well as trying to push specific paths we decide on.

    Kelsey: with user testing, is there felxibility about how we do
    it? Ideally we can do it before, during, after developement.
    Are there specific guidelines on what we should be doing?

    CH: I have some opinions... we should determine that a
    prototype is ready to test. In testing, we should have a fairly
    common base methodology.
    ... a simple written statement can help allow multiple people
    to conduct testing and be able to usefully compare their
    ... we have to test including people with disabilities as part
    of testing.

    [general agreement on that point].

    Kelsey: Maybe there is an opportunity to test before
    developing, to guide the developemnts

    CMN: It is useful to do testing before development, but I would
    avoid trying to formalise the process on pre-development
    testing, sowe minimise constraining thinking and work that has
    high cost for little extra benefit. I think it is important as
    CH said to have testing that is consistent post-development, so
    we can compare results across different tests and different
    prototypes tested.

    Kelsey: Hope we don't stop people from doing early testing by
    being too tied up in methodology and formal requirements at
    that stage.

    CH: we are trying to find out whether what we do is usable -
    including for people with disabilities. SO we need some
    heuristics that explain what are we trying to find out / check,
    and what is a way to discover that.

    JS: We can share that so people working on prototypes can be
    guided. But doesn't it vary by what peice of a prototype we are
    trying to do?

    CH: we may have less testing for e.g. a new way to write
    success criteria

    JS: So how do we approach this? I am looking for help in this

    CH: Think we should have some general guidelines on how to do
    this, without putting constraints on what people do.

Summary of Action Items

    [NEW] ACTION: JS to check what it costs to use the ISO standard
    on Plain Language
    [NEW] ACTION: JS to Talk to people who know about whether the
    Plain Language standard is suitable.

Summary of Resolutions

    [End of minutes]
Received on Friday, 30 March 2018 15:23:34 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:31:42 UTC