Silver Conformance Options Subgroup

10 March 2022


1, Azlan, DarrylLehmann, GreggVan, janina, jeanne, KimD, maryjom, PeterKorn, shadi, Wilco
example use case was a third party pushing updates faster than they can be tested, janina, jeanne

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).


Succeeded: s/come up with some proposals/look at this in particular

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