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?