[Conformance] Minutes from 10 March

Minutes from the Silver Conformance Options subgroup teleconference of
Thursday 10 March are provided here.

===========================================================
SUMMARY:
* Continuing refinements to situation and example scenarios doc;
* Discussion on how best to order the situations in the doc
* Discussion on how to present this rather long doc most effectively
===========================================================

Hypertext minutes available at:
https://www.w3.org/2022/03/10-silver-conf-minutes.html

===========================================================

   W3C

                                                                                                            – DRAFT –
                                                                                               Silver Conformance Options Subgroup

10 March 2022

   IRC log.

Attendees

   Present
          1, Azlan, DarrylLehmann, GreggVan, janina, jeanne, KimD, maryjom, PeterKorn, shadi, Wilco

   Regrets
          Todd_Libby

   Chair
          Janina

   Scribe
          example use case was a third party pushing updates faster than they can be tested, janina, jeanne

Contents

    1. Agenda Review & Administrative Items
    2. User Scenarios Review https://www.w3.org/WAI/GL/task-forces/silver/wiki/Substantial_Conformance/Example_Scenarios
    3. situations 8 and 9
    4. Situation 8
    5. Ordering the Use Cases

Meeting minutes

   <janina> Date 10 Mar 2022

  Agenda Review & Administrative Items

   JS: We need to think about how to present this to AGWG. I timed my screenreader which took 45 minutes to read. I think we need to think about a summary and how to handle details.

   JS: Should we meet next week? It is the CSUN week.

   WF: not available

   PK: would want to leave early,

   JS: We aren't presenting to AGWG until the 29th.

   <DarrylLehmann> +1 on schedule

   JS: propose skipping next week, meeting on the 24, presenting to Silver on the 25th.

   <PeterKorn> +1 to inviting Judy again

   SAZ: We may want to invite Judy again

   JS: Shadi sent her an update a week ago
   
 we should hear her concerns

   SAZ: We have addressed her concerns, now we should look at her recommendations for next steps

   JS: I will followup with Judy

  User Scenarios Review https://www.w3.org/WAI/GL/task-forces/silver/wiki/Substantial_Conformance/Example_Scenarios

   JS: I love the way it reads with the latest updates

   SAZ: I think the Intro part is very important
   
 1) walk through the changes
   
 2) look at 8 & 9
   
 3) go up a level and think about the order of situations and examples, especially what we lead with. First impressions are important

   JS: I had a structural thought on presenting it to AG. If we named the examples and built the table of contents so they would cluster under the section which would give a better sense of what we are proposing

   SAZ: I didn't address every comment but I did take the major comments

   SAZ: The Approach section is improved
   
 all the "can" to "might"
   
 made "accessible" more consistent. Removed "partial conformance"
   
 used "conforming" to apply to standards
   
 In situation 2, when content is rarely used. I kept the weather forecast report.
   
 I separated the content into "outdated content" and "current content rarely used"

   PK: Outdated vs Current: the important example in situation 2 is that content that is generated contemporaneously, but we don't know when it will be meaningful.
   
 Outdated doesn't fit with it, but we don't know it is important until we want to look back on it

   SAZ: That would make it too close to Situation 3

   <janina> +1 to agree a different accumulating example might communicate better than weather; but weather will do until we have a better one!

   PK: Trying to look at this with a critical eye, when we say "library" it is a place where everything should be accessible. A better example would be searching for exoplanets where there are thousands of photos and we
   rarely every go back to. We archive them in real-time because we will only look at them again if necessary.
   
 this feels more like "content rarely used" than "content accumulating too rapidly". We have no idea if we are going to use the information that is being captured very rapidly.

   SAZ: (reads) Example 2.2 - current content that is rarely used: An organization is continuously archiving thousands of electronic titles, including of digital books, video and audio recordings, scanned documents, and
   more. It ensure that those presented to the general public, for example displayed in an exhibition, conform to the technical standard. However, the majority of titles are

   archived and very rarely used. Occasionally, researchers, collectors, and others may be interested in the one or other title for particular reasons. These rarely accessed titles are marked to all users as archived,
   for example in a banner that conforms to the technical standard. The organization decides not to prioritize retrofitting archived titles, to make them conform to the technical

   standard. The organization indicates in an accessibility statement that archived titles may have accessibility issues, and describes the types of issues that tend to occur in these titles. The organization also
   provides a mechanism for users to request conforming versions of archived titles, for example for research purposes.

   PK: It uses "digital books, video and audio". Digital books should be accessible. We are trying to capture the concept that we don't know if it needs to be accessible until we go back later.

   DL: We could replace the word "digital books" with "point form notes"
   
 I really like the improvements

   JS: Astronomical observatory

   jeanne: Like how the doc has developed; it's direction and examples

   jeanne: Only concern is how long it takes to read

   jeanne: perhaps a presentation format for AGWG where we describe hiding much of the detail

   jeanne: also have another use case, but later

   SAZ: I'm running out of ideas of how to make it more readable

   DL: I think it has a lot of potential to help out the broader group
   
 maybe we could hide out the technical and policy sections with dropdowns
   
 maybe we could go into the first example in details, with less detail in the later doc

   PK: Rather than adding to the main document, putting a summary in advance with an invite to read the details
   
 we could use expand/collapse more

   SAZ: Expand/collapse can increase more usability issues
   
 we could put it in a survey in breakdown so people can read it.

   JS: The calligrapher example needs more work to fully explain what we want to accomplish.

   SAZ: I want to look at the order so that the first example has the most interest to the group so that they want to read more

   SAZ: HOMEWORK: Take a look at the Introduction section and make it clearer. On list or offlist or pidgeon

  situations 8 and 9

  Situation 8

   SAZ: We only have one example. The 8.2 example was removed because it really was a technical issue and fit better in section 9

   SAZ: the real-time example could fit into 9, and couild have a shorter document.

   PK: I had more examples for real-time: Plain language and language simplification which cannot be done in real-time
   
 when it is in multiple languages, you have to wait for the translater first, then the caption. That makes real-time captioning much more difficult.

   JS: I am open to either option, and also open to changing the order
   
 what principle we use to reorder is important.

   <DarrylLehmann> +1 on merge for page size

   jeanne: Like them separate

   jeanne: the Real Time aspect is important to keep separate from current limitations

   jeanne: could live with it -- but ...

   shadi: the real time would still be there

   jeanne: 9 is broader -- applies across more technologies

   jeanne: 8 is unique for RTC

   jeanne: Feels a bit lost in 9

   <maryjom> +1 to what Jeanne said. I think these are separate conceptual situations.

   PeterKorn: could we do it via example in 9?

   jeanne: yes

   <jeanne> PK: Could we put it into the title, that way it addresses the problem of it getting lost

   <KimD> +1 to merging AND +1 to adjusting the heading in 9

   <jeanne> MM: Technology and time are different concepts, but addressing it with labeling is fine

  Ordering the Use Cases

   <jeanne> SAZ: The order is just what occured to me as I wrote them, so it may be subconscious. I don't have a suggestion of how to reorder it.

   <jeanne> ... Janina suggests adding the example headings to the table of contents

   <jeanne> ... then the order of the examples is more important

   <jeanne> PK: We want to put the most common and least controversial at the top

   <jeanne> ... we don't want to exempt for all time, but they are not controversial today

   <jeanne> ... the standards change is another one that will resonate with AGWG

   <jeanne> ... I like the idea of closing with small business at the end

   <jeanne> jsp: +1 to Peter's suggestion to reordering

   <jeanne> DL: So many companies depend on outside services, example 4 should go further forward

   <jeanne> PK: I disagree. I see the list as everything that needs to be considered, but it is more controversial, and we want to get people onboard before they confront more controversial material

   <jeanne> DL: Buy-in is important, then we could address the more nuanced material

   <jeanne> SAZ: What would the top be?

   <PeterKorn> +1 for Real-time / Current tech limits early in list

   <DarrylLehmann> +1 on realtime

   <jeanne> JS: I think real-time: 8 & 9 first

   <PeterKorn> I'd keep 6/Bugs in later half of doc

   <KimD> Nothing new from me

   <jeanne> GVH: I will read it again

   <PeterKorn> I like the idea of putting 1 and 3 next to each other, as both are speaking to "large volumes of content"

   <jeanne> SAZ: "realitive accessibility" still needs more work, so Gregg, please look at this in particular on.

   <jeanne> GVH: I don't have good solutions. It would be a tragedy if pages about accessibility were inaccessible. Instead of making them a priority, we could address them as "of course, the accessibility pages have ot
   be accessible"

   <jeanne> PK: The example might be a service like ParaTransit. A service that is specifically aiming at people with disabilities. It needs to be at the top of the list.

   <jeanne> GVH: we don't want to say that something is a second priority or a lower priority, just that accessibility of accessibility has to be an "of course"

   <PeterKorn> Jeanne - maybe a new example in section 5?


    Minutes manually created (not a transcript), formatted by scribe.perl version 185 (Thu Dec 2 18:51:55 2021 UTC).

   Maybe present: DL, JS, PK, SAZ, WF

-- 

Janina Sajka
(she/her/hers)
https://linkedin.com/in/jsajka

Linux Foundation Fellow
Executive Chair, Accessibility Workgroup: http://a11y.org

The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
Co-Chair, Accessible Platform Architectures http://www.w3.org/wai/apa

Received on Thursday, 10 March 2022 18:05:42 UTC