Silver Task Force & Community Group -- 27 Mar 2020

<sajkaj> Are we? The old Webex code?

<sajkaj> OK

<CharlesHall> problem with audio, Jeanne

<CharlesHall> finally have audio. phew.

<CharlesHall> https://www.w3.org/2020/03/24-ag-minutes.html#item05

<CharlesHall> https://www.w3.org/2020/03/25-ag-minutes.html#item07

<jeanne> https://docs.google.com/document/d/1QF5Olq8880_OmP0Eyr7CmFti5O1VIFUXPhguA6DFzlE/edit#heading=h.2dd4ztqnl15w

<Rachael> scribe: Rachael

Bruce: Business about reliable, testable, repeatable is not part of normative. That is why we've been struggling. Other normative standards have things that are not so reliable, testable and repeatable. I think it would help us to separate out that expectation.

Jeanne: +1

<Lauriat> +1

Jeanne: I think we will need to discuss it more. Some people feel very strongly that it needs to be a very narrow interpretations. I think that is something AG needs to agree with. It was good to see how many people already agreed with it. That rocked.

Kim: Are you saying we do want it to be reliable, testable, and repeatable?

Jeanne: I think some people do want that. I think others want a broader approach. There are some guidelines that already exist that can be reliable, testable and repeatable. We should do that when we can. To apply that to everything would make it difficult to do all we want to do and meet that.

Kim: Thank you. I just wanted to make sure I was on the same page. That is my thought too. With WCAG 2.1 series, that is where we had a lot of struggle with the COGA content.

Shawn: We can have repeatable and reliable tests that depending on the person's perspective may have variable results. I think we should have tests that people can replicate in various places. We can know we are doing the same test even if our results disagree. It gives us a framework to come to a result and discuss a resolution. As opposed to a repeatable results - which some tests have today but many do not.

Kim: Thanks.

Charles: Are we still aiming to create and rely on a definition of what is normative and what is informative?

<bruce_bailey> Alastair pointed out that "normative" is in WCAG 2.1 glossary

<bruce_bailey> "normative: required for conformance"

Jeanne: I had an exchange with Michael C earlier. We may not want to write a definition because we'd need approval from a lot of different places. My own thought/speculation: There is a reason why W3C does not have a normative definition of normative. For 30 years, if they wanted one they'd have it. It was possibly decided long ago that a definition of normative would be too restrictive. There are very few W3C specs that attempt to define normative

- WCAG is about the only one we can find. I think we'd do well not having a definition.

<bruce_bailey> https://www.w3.org/TR/WCAG21/#dfn-normative

Charles: I am mostly satisfied with that answer. I don't agree/disagree with that but I do think we still have a vocabulary problem that was evident in that discussion. For example Guideline vs Standard.

<Zakim> bruce_bailey, you wanted to say definition is in WCAG 2.1

Bruce: WCAG 2.1 has normative as a glossary term. It just means required for conformance. See link above. This discussion of normative vs. non-normative isn't the issue. I think the key issue is repeatable, reliable, and testable.

<PeterKorn> +1 to liking adjectives

Jeanne: We went through the current silver proposal, Bruce's two currency proposal, and Bruce's proposal for adjectival scoring which got a surprising amount of support. And John went through his proposal on scoring headings. I want to talk about these and start talking about how these fit into what we have and how to test them.
... As the person who tested the scoring mechanism we have so far, I wasn't thrilled with it and I'm excited to work out the details of how the adjectival could be integrated. I'd love to test that because I think it will potentially be an easier way forward.

Bruce: I think it's already possible to test this becuase its so lightweight. I'd like to add keyboard accessibility and another so we have 5 things to rate. Then I and others can rate and compare answers.
... if it works on a static site, we can then iterate on more complex examples.

Jeanne: Given our current structure, where would you like the adjectival ratings?

Bruce: I think they need to be high level and surface them.
... I think we are just doing them for websites which lets the methods be informative.

Jeanne: What do you think of as part of each guideline, we'd have the guideline, the functional outcome and the adjectival rating as a result of the outcome?

Bruce: I think that could work.

Peter: I'm curious if you see a way to meld an analysis of the importance with the adjectival rating.
... I think the two can work together. We've done something like this for Amazon.

Bruce: I think that flashing would have to be rolled into a guideline so it didn't outweigh keyboard accessibility. But it could be rolled into a larger guideline.

Peter: Not quite what I was asking but I do like that because then we could integrate A/AA/AAA. It would say is what we need to be great (AAA), What we need to be good (AA), or what we need to do to barely pass (A). It doesn't say what we need to do to make something fully accessible. My example is the demarcation of space around the footer - If its wrong it doesn't really effect anyone. Logging in, search, etc are more important than other parts
... such as whether the review by one person on a product doesn't include sensory characteristics. Maybe you do this in the rollup. Lets say we have a page that has one excellent and two good. And the excellent is in something not important but the goods are in important areas so we only make it good. How you do that mechanically is a big question. I'd like to see us start tackling that in our language.
... even if we don't have detailed thoughts about it.

<bruce_bailey> +1 to more peoples minds

<Lauriat> +1

<Lauriat> ach Rachael

<jeanne> scribe: jeanne

Rachael: Having clear definitions of what you are looking at. The challenge is having it in a granualar examples.

<bruce_bailey> i agree that definitions for excellent / good / acceptable etc. very critical

<Rachael> Scribe: Rachael

Rachael: The definitions are critical and can balloon quickly.

Peter: Jeanne asked, Where would you put the adjectives in our structure? We could try working those in and see how that feels.

Jeanne: We should probably try it in a few places. The adjectival rating is one of the things that we were working on in the clear language group when we were trying to talk about the rubric. We ended up not going in that direction but that is one place we can put these but that wouldn't be normative. But we should try it. Also try it in the main document itself. If anyone wants to draft examples of what that might look like, I'll put that in the

document otherwise I'll take a stab at putting them in. Is there any other place they could go?

scribe: I think there is some reason to put them with the test.

Shawn: I would prefer to figure out how it could work and get a solid sense of that. By going through that process we could figure out where it lives.

Jeanne: Would the people who worked in the subgroups take a stab at writing these?
... I'm willing to go through another test of the website I tested a few weeks ago and do it with the adjectival ratings.

Chuck: I can speak with my peer to see if he can help.

<Lauriat> Thanks, Chuck!

<bruce_bailey> chart so far:

<bruce_bailey> https://docs.google.com/spreadsheets/d/1G0KLv1Nfvy5QWN7t9jPxyE6UEcTHE5A8tKYiDOhuZRY/edit#gid=1833982643

Jeanne: I think that would be easy to go with adjectival. Possibly mathematically based. It could be in the chart. Here's the number you get running the test. There's your rating. You'd likely have to average your rating of color combinations throughout the website. Bruce, what do you think?

Bruce: I think the big advantage of the adjectival rating is that you spend as little or as much time evaluating a webpage as you care to. I am pasting in what I had so far:

<bruce_bailey> Content does not specify font characteristics.

<bruce_bailey> Or, default body text size is a sans serif font between 16px and 32px with |SAPC| of 100 (or more). All other text, other than logo and incidental text in photographs, satisfies values in “Accessible Contrast by Font Size and Weight” table.

Bruce: we could do that in a lightweight way

<bruce_bailey> Or, content provides “style switcher” type widget (or control) where at one choice is light text on a dark background with body text at 16px or larger.

Bruce: How things currently test is you look for things that are weak and look at those. That gets you to average, acceptable, etc.
... there's lots of things in between. For example a site with a style switcher where the switcher does not fix tiny low contrast text in the footer.

<CharlesHall> this seems to align to the FICO score model but at individual guidance level versus overall score

Jeanne: I'm considering where to talk about John's proposal. We had it last week with the headings example but I'm not sure where to keep going with that.
... Bruce, did you and John work out a way that both could coexist? Did you determine one or the other?

Bruce: There was a conversation about a detailed numbering system being compatible with adjectival ratings. I will point out that the whole point of the adjectival rating is that you can do it light weight. If you have to calculate a FICO score, it defeats the approach.

Jeanne: The other work he was doing on headings, where he was splicing the functional outcomes with functional needs. Can we do something with that?
... I think there is value in giving a score by disability category.

Shawn: We've talked through given the functional needs, having a minimum score by functional need. If there are 7 functional needs, 2 don't apply, 3 are good, and 1 is lousy, you get the worse score.

I think we can apply this score by functional need. I think it will be easier since we wont have a lot by functional need. I feel like I'm adding complexity and I'm not sure if that is helpful or hurtful.

Jeanne: John is working on this more. I'd like to see how he's advanced it.

continue discussion of integrating different proposals in Silver model

Using "Structure" instead of "Heading"

Jeanne: One of the AG members suggested changing Heading to Structure as it is a more technology neutral way of expressing the need.

<jeanne> https://lists.w3.org/Archives/Public/public-silver/2020Mar/0070.html

Jeanne: [Reading email]
... What do people think?

<bruce_bailey> +1 for structure over heading (bc "heading seems very html specific)

Shawn: I like that as an idea. You can meet the functional need through headings and semantic structure. Some technology relies more on headings and some on semantic structure.

<jeanne> +1 for changing Headings to Structure

Jeanne: I want to avoid an overpacked guideline -- but perhaps that is what we do want.

<KimD> +1 to "structure"

<bruce_bailey> headings already pretty broad, i would not like to see it merged with 1.3.1

Jeanne: Cyborg suggested grouping things together in an overarching topic like readable. And Alastair suggested broader topics. Maybe this does fit in this idea.

<bruce_bailey> agree that there may be some aspects of 1.3.1 that go to our heading/structure GL

Shawn: I think there is aspects of 1.3.1 that we can put into various parts of other guidelines. Pick apart what is important and why they are important. Use semantic structure on containers. That makes it clear what we are trying support.
... some things fit into multiple categories.

Jeanne: I wasn't thinking we add another layer. One of the things alastair said was the ability to look for things that were not currently covered in the guidelines. Things that fall through the gaps because nobody thought of it. Systematically think about what's needed.
... so we're not just migrating what we have.

Shawn: I think we are off to a good start with the outline. We want to migrate what we have today. As part of that process we've already started writing new guidance. Keeping the scope narrow to start is helpful and along the way we can flag to dos. What we have today is the tip of the iceburg. I'd like to avoid expanding the scope of the first publication. I agree with alastair but not yet.

Jeanne: The thing about not publishing before CSUN is that we lost our deadline.

- DRAFT -

Silver Task Force & Community Group

27 Mar 2020

Attendees

Contents

continue discussion of integrating different proposals in Silver model

Using "Structure" instead of "Heading"

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output