Silver Community Group Teleconference -- 24 May 2019

<Lauriat> Where we left off: https://docs.google.com/document/d/1aCRXrtmnSSTso-6S_IO9GQ3AKTB4FYt9k92eT_1PWX4/edit#heading=h.t5lsu36jh50k

<Lauriat> https://www.w3.org/TR/WCAG21/#parsing

<Chuck> Scribe: Chuck

Lauriat: Last time we walked through this, SC 4.1<audio glitch> Parsing was to use markup correctly.
... Denis was raising a point about parsing.

<Lauriat> Start off with Understanding documentation: https://www.w3.org/WAI/WCAG21/Understanding/parsing.html

Lauriat: The 3 things that are in the SC... <reads> My <Shawn's> understanding of these ... is what the SC is trying to do.
... <reads intent>
... re-enforces my understanding.

<JF> https://developer.paciellogroup.com/blog/2015/11/wcag-2-0-parsing-criterion-is-a-pita/

Chuck: Brings up that agwg is considering deprecating.

JF: Most of the browsers... what's important is what gets written to the DOM. all of the browsers remediating.
... Poorly nested elements get correct by the browser.

Lauriat: SVG as well?

JF: Couldn't tell you, may vary from browser to browser.
... Browsers are very forgiving. The most important one is avoiding duplicate ID's.
... In WCAG 1 there was a req that the code had to validate. They wanted to back off on that a little bit.
... Rolled back to proper nesting, duplicate attributes and id's. Error handling is a little bit uneven.

Lauriat: Thanks for explanation.
... I land on "use valid markup". There may be other errors.

JF: If the code is so bad, it won't render in the browser. Those kinds of code errors, most content creators will test right in the browser before going live.
... If they have written bad code, it will be caught. Can't think of a use case where the browsers won't remediate right now.
... We do recommend using valid markup. Even though not a requirement to run through validator, we craft, and pride dictates that we run through.
... As Chuck WISELY and SUSINCTLY noted...

Lauriat: I can think of things beyond the things in SC that impact accessibility tree.
... CSS is not impacting elements as intended. You can switch a block level element to an in-line element, making some rules ok.
... Where I'm landing on this is maybe having 2 methods. First would be current SC guidance. Under that would be...
... What denis lists. Second higher level method would be to use valid markup.

JF: Assuming moving from one apartment to another, but if 4.1.1 is deprecated, we may need to remove from Silver.

Chuck: Concerned about being specific to markup.

Lauriat: Another method could be that if you are creating another tech stack, use that tech stack correctly.

JF: It does feel like another method. Ensure content is created that supports all the accessibility technologies in the selected stack.
... Abstract it out. iOS, Android, PDF.. they all have their technologies.

Jeanne: Follow and adhere to the accessibility guidelines of the platform.

JF: Do we want to say "platform or technology"?

Lauriat: Yes, that is good.

JF: A sideline to the methods, in IRC I pasted a link to a blog post. At Deque, run the code through W3C validator, apply SF's
... Filtering...
... In terms of methodogy today that's how we validate 4.1.1.

Lauriat: Moving on to 4.1.2 Name Role Value
... All of these are kind of the same thing. Use the technology as you are suppose to and don't break things. But we can discuss in it's own context.

JF: The difference here is that the parsing one is parsing existing code, 4.1.2 is about custom scripted widgets. Using proper aria markup.
... This says "when you create custom widgets, use aria".

Lauriat: That's how I read it, but it's written more generically.

JF: As caveate, intended to say "use Aria", we we get into other platforms where Aria is N/A....
... So should be abstracted.
... Include name, role, value AND STATE.

Lauriat: Same underlying user need, make sure it works with AT.
... I'm inclined to group it with the one above.
... <reads>
... This is just another way of parsing it.

JF: More than just parsing. Parsing is older model, this is way more about interactive elements is conveyed to accessibility tree. Slightly different.

Lauriat: Slightly different place in the tech stack about how things get to the AT, but same fundamental user need. Make it work with AT.
... This is a very specific piece of it.
... Still it's "make it work with AT".

JF: First is "make sure it's consumable", 2nd is "make sure it's actionable".

Lauriat: Good way of putting it.

JF: Not sure how or where we capture that...

Lauriat: What do you think about these being separated or consolidated?

Jeanne: They should go in methods.

<AngelaAccessForAll> I think consolidated.

Chuck +1 to consolidate.

JF: What's the underlying requirement?

<KimD> +1 to consolidate

Lauriat: Make sure it works with AT.

JF: The AT may not be electronic. May be hardware or something else.

<AngelaAccessForAll> +1 to work with AT.

Lauriat: The AT isn't responsible for parsing. We are moving into a world where that is no longer going to be the case.

JF: The consumable by all may include users who aren't using AT. Lots of users... we have a video of mobility show's man in wheel chair using mouse stick.
... If sections of the page don't render properly, he can't use it.
... That's the only distinction.

Lauriat: The intention of the first one is also about the accessibility tree. iOS is strict about nesting.

JF: I understand. I'm saying 4.1.2 is directed towards the accessibility API's, but the first one could have a broader impact outside of accessibility API.
... First is about DOM, second is about accessibility tree.
... Dom for all is first, DOM for some is second.
... I agree we can compact this into a single requirement.

Lauriat: I added "consumable and actionable".

JF: I would make sure that in this document we have a note to pay attention to AGWG.

Lauriat: Done.
... On the very last SC. 4.1.3 status messages.
... <reads>
... 2 pieces to this. One piece can be through ARIA. If you use browser status I don't think that reads out. This sounds like Aria live.

JF: This is a 2.1 SC.
... I think this was split out is that there is more than just exposing name, role, value. We are trying to say "use aria live", the prob
... ...is that we need to keep it abstracted so other tech is covered.

Lauriat: So this is about interacting with the accessibility tree.

Lauriat: This is kind of the 3rd prong of grouping. If you have status messages, make it so that they fire events so that AT knows about them.

JF: <reads scope>
... Do we want to include scoping in document?
... Feels like it sums up the user requirements.

Lauriat: I'll copy those in.

JF: We are in fact merging all 3's into one umbrella SC. Turned the principal into an SC.

Lauriat: Yes.

JF: Make it work everywhere and don't leave anybody out!

Lauriat: We have done a first pass! WOW!

Jeanne: WHOOHOOO

JF: I noticed that people miss out section 7. We defined taxonomy. Put there so that we could severe dependence on HTML 5.

<Lauriat> Section 7 that JF brought up: https://www.w3.org/TR/WCAG21/#input-purposes

JF: Going forward taxonomy be contained in new silver guidelines. Should be preserved.
... Don't know how to do that in silver, but it's CRITICAL consideration. This is the normative list for SC 1.3.5.

Lauriat: Very good point. Reviewing now...

JF: We haven't talked about in Silver yet, that Silver will contain random bits of normative text. We've been doing a mapping.
... This is an intergration requirement.

Lauriat: Which SC?

JF: 1.3.5 purpose of inputs.

Lauriat: I'll add a link to that.

JF: This one is about not so much related to robust, it's more about supporting....

JF: Where you've merged 1.3.1 and 1.3.5 together.

Lauriat: This is the ... <reads>

JF: Right. What's being missed here is that 1.3.5 has some specific scoping requirements.
... <about taxonomy>

Lauriat: I'm adding note on this method, and linking to section so we know to migrate that in.

JF: We need to discuss "migrate".
... AS long as we don't lose it.

Lauriat: That's my goal.

<Lauriat> Comment: https://docs.google.com/a/google.com/document/d/1aCRXrtmnSSTso-6S_IO9GQ3AKTB4FYt9k92eT_1PWX4/edit?disco=AAAADDZsdwY

<JF> scribe: JF

Next step is to move this to a wiki page for wider review and comment

Jeane: will work with Shawn on that migration

Updates to Silver Content writing process

Chuck: grabbing a link

Did some work on this this week, but did not make any progress (advance) - ended up discussing the process

additional thoughts about the process of parts 2.3.4

Chuck: started reviewing the tests, but then, could we map those tests to the user-needs

are the test matching user needs and/or is there a user need we're still not addressing?

Then started to look at the methods and discussed the design process

Chuck: this is roughly from memory or our call

<Jan> Is this the link to the color contrast notes: https://docs.google.com/document/d/17tWKnweNC-BJunhtPTGtbYhV2D6VPYDxEofazhGG3Pw/edit?usp=sharing

intent is not to dictate the process, but rather of thinking about the test itself

[discussion w.r.t. ongoing discussion at AGWG]

<KimD> "Color contrast tutorial" link: http://colortutorial.design/index.html

Chuck: hoping this discussion is more about process rather than actual tests
... also introduced the idea of high contrast and what that means

<Jan> Page 2 of 8 are the notes we took about the process for writing about guidelines, but the notes were taken inside of the Color Contrast draft from AccessU: https://docs.google.com/document/d/17tWKnweNC-BJunhtPTGtbYhV2D6VPYDxEofazhGG3Pw/edit?usp=sharing

Bottom line was a conclusion that likely we need to map user-needs to tests, and then tests to user-needs to ensure we don't have any gaps

Cybel's notes recognizes both existing and new techniques

which then lead to the discussion about how do we ensure that our test meets all the user needs?

Jan: email went out today (limited distro) that expands on this further
... will copy that to the folder, then will send out an email with the link to the document

<Jan> https://docs.google.com/document/d/152RdsWpzq0QqdiSeW2dk0-RTp6QZkbcOZevbfa0tQMo/edit?usp=sharing

Chuck: once this is shared more widely, then we can discuss in more detail

<johnkirkwood> I requested as well ;)

Chuck: as we wait for sharing of this doc, propose we return to this next call

Shawn: good idea as we're at the4 top of hour

<Lauriat> trackbot, end meeting

- DRAFT -

Silver Community Group Teleconference

24 May 2019

Attendees

Contents

Updates to Silver Content writing process

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output