<PeterKorn> Sorry, having some audio problems...
<PeterKorn> There we are!
<CharlesHall> will that change the date for FPWD?
<jeanne> Jeanne: There were plenty of votes in favor, but some formal objections. That will be worked out with W3C Management.
<jeanne> Michael: Substantial changes will have to be approved by the working group
<jeanne> Charles: Will that change the date for the FPWD?
<jeanne> Michael: If the charter isn't approved in time, then we would have to wait until it is approved to publish,
<scribe> Scribe: Lauriat
<CharlesHall> https://docs.google.com/document/d/1D1AczVDgSCgCci4t3sO-QV6VKaKIEyQ6zKgm0ocnFB8/edit?usp=sharing
<CharlesHall> People may have difficulty locating content due to: human factors (like low vision); technical factors (like system generated scroll events); or contextual factors (like resizing the viewport), when they lose a point of regard.
Charles: Two slight variations in
this choice of wording from the proposal in the migration
document.
... Bolded a word in the document attempting to identify the
end result functional user need, coming from our discussions at
TPAC around writing functional user needs.
... The end goal is locating content. Added two around
navigating and understanding content.
... The technical and contextual factors then apply to the end
goal of the user.
... After the user needs, paraphrased the guideline [reads]
"Preserve the user’s point of regard (what they are looking at) when the content size or window (viewport) size is changed."
Charles: Whenever the user changes this context, keep the top-left content at the same place. But to me that doesn't necessarily meet the end goal, it just makes one method of meeting it.
Added other examples in the document.
Jeanne: LVTF is also looking at this and they've made a number of edits. Are you both working in the same document?
Charles: Working in the document you shared a few weeks ago? Looks like a shared document?
Jeanne: Yes. Glad you're working in the same one!
Charles: I specifically appended the document so I wouldn't interfere with other edits going on.
Jeanne: I know you felt a bit constrained by the previous wording, but did you give thought to how to get beyond the upper-left wording?
<CharlesHall> The user agent can maintain the point of regard based on known input cues such as: zoom via keyboard; zoom via multi-touch gesture; zoom via double tap gesture; orientation change; or viewport resize.
Charles: Through tests aligned to
methods.
... The idea here: a method that can be accommodated by the
user agent itself, but doesn't have the mention of the x/y
coordinate.
... A test accompanying the method would do that.
... It could have the opposite approach, where one method would
explicitly say that in order to preserve the point of regard,
you would need to keep the x/y coordinates. But I thought the
level of specificity would go into the tests.
Jeanne: Great, thank you! Questions?
Charles: I have a general question. The end goal word, is that a clear direction to understanding the user need?
<Cyborg> I would like to have an offline chat with Charles about this.
<CharlesHall> my availability for offline conversation: https://calendly.com/accesstoday/accessibility?back=1&month=2019-10
<jeanne> Shawn: I think it helps. We want to have an idea of all the ways it can help people, but not necessarily listing all of them out. I think it is helpful
Lauriat: I think it's helpful.
Jeanne: As a reminder, all of these documents are linked to from the main page in the wiki.
Cyborg: We have been using this
process that we've used for other guidance and it seems to work
well so far.
... On page 1, groups and barriers, relating to plain
language.
... [reads down the list from the document]
... A lot of complexity, nuance, and disagreement. For example:
in the UK they call it "learning differences" vs. North America
"learning disabilities"
<Fazio_> COGA is creating glossary of terms for this
Cyborg: We've created a list of common needs.
Nice, thank you for mentioning!
Cyborg: We looked at unique needs separately. For instance where added detail may help some users but make it harder for other users.
<Fazio_> Sight words are important
Cyborg: We then looked at the
"how", breaking it down into three groups [reads
headings]
... On to the "why", which we just added this morning (first
draft of a first draft).
... The "who", we're running into the same problem. We want to
communicate a diversity of needs recognized, but without
putting people into boxes.
Jeanne: If you think back to the
plain language prototype, the "who", "why", "how" came from the
plain language prototype.
... Steps 1 - 4 won't necessarily go into Silver, but help us
work through things. Further steps will.
Cyborg: Step 8, exceptions, we've come up with one so far (emergency notifications).
Fazio: One of the most important things is "sight words", so using words that people can recognize them in fractions of a second in order to then better understand them.
Jeanne: Do you know how that can fit in the user needs?
Fazio: First time seeing the
document, so not sure yet.
... Will add a link to more information on this.
Cyborg: Definitely invite everyone to comment on the content of this as well as the structure!
Jeanne: The tests and methods sections are a bit messy so far, still working on that.
<PeterKorn> +1 to Charles - putting this into it's own SC
<jeanne> +1 to isolating "sight words" as it's own guideline
Chuck: Fazio, you said one thing in particular that blew my mind, how recognizing and understanding the words is even more important than the use of plain language.
Charles: That conversation also occurred at TPAC. My question: there was a comment that steps 5 - 8 are content for the get started tab in the plain language prototype. So I'm confused as to how that would occur and whether it would create redundancy.
Jeanne: 1 - 4 wouldn't to into Silver directly. Getting into 5 and 6, those would go into the Silver equivalent of Understanding.
Charles: Not the language of this document, repeated.
Jeanne: Right.
Cyborg: The information that people put in, they wouldn't necessarily focus on the plain language itself. These steps are to encourage exploration of user need and then communicate it in a way that people can understand. The process is to center people on user need, see what comes from that, and then communicate it externally.
Charles: These are simply the instructions for what to come up with for that tab?
Cyborg: Focus on the user need and then try to communicate that.
Peter: Riffing on the sight words, what are the techniques most helpful for people for whom sight words are most critical and at a deficit?
Jeanne: I think that's a great question, but I think one for another day.
Peter: More of a request for more links to information about that.
<CharlesHall> +1 for bringing sight words research into future discussion
+1
Chuck: Part of this is really bringing up who can participate...
<Fazio> Sight words post 1 of 2 https://www.linkedin.com/posts/davidpfazio_cognitive-disability-languages-activity-6523267236088684544--xlj
<Chuck> Chuck: scribe
<jeanne> jeanne: I updated the Explainer document on Github. It's not complete but it is moving over
<PeterKorn> Am I not audible?
<PeterKorn> Sigh.
<PeterKorn> 45 min after the hour.
<PeterKorn> Give me 60 sec.
<Fazio> Site words post 2 of 2 https://www.linkedin.com/posts/davidpfazio_cognitive-a11y-comprehension-activity-6523617282961342464-8X4t
<PeterKorn> WebEx and my computer do not get along
<jeanne> https://docs.google.com/document/d/17ByXEqqXuqWtDzxq2J6Vch27n4RWMZig7P426aPiIto/ <- Challenges
<Chuck> pk: experiencing audio issues. He is working the issue on his side.
<PeterKorn> ~halfway through reloading WebEx...
<Chuck> yes
<Chuck> pk: Is audible
<Chuck> pk: Several have been working on this doc ... the main pieces... we have a 4th section/category of challenges related to non-web tech.
<Chuck> pk: Swapped the intro to a background. In the background pre-pended content some discussion about the language of WCAG 2.x conformance.
<Chuck> pk: If the page can't conform, it cannot be scoped in the claim of comforance ... <continues to read>
<Fazio> my curiosity about the sight words is how or if it applies to non western script languages that use completely different phoenetics
<Chuck> pk: We add several sc criteria in section 1. We have 1.4.1 and 1.4.5 (others). Challenge 4 has a start, looking at special conformance when we try to bring WCAG 2.x model to large/complex/dynamic non web itc.
<Chuck> pk: Would love to hear comments/suggestions or edits.
<Chuck> pk: Will discuss at AGWG next week. To keep this on a good glide path to publish in or along side fpwd of silver.
<Chuck> pk: Apologies didn't get it out before this morning.
<Chuck> pk: Christmas at Amazon!
<Chuck> pk: Any comments, q or reactions?
<Chuck> Jeanne: Happy to see the challenges for the individual sc. Very helpful, looking forward to reading.
<Chuck> pk: Thanks. Some non-silver agwg have commented.
<Chuck> pk: We will try to get this up before tuesday.
<Chuck> Jeanne: Which github? Silver?
<Chuck> pk: What's the preference?
<Chuck> Jeanne: Let's take it offline.
<Chuck> pk: Thx.
<Chuck> bruce: This is very timely. Side discussions at the inter-agency accessibility forum earlier this week.
<Chuck> bruce: We need to think about what a post testing world looks like. The reason is all the issues in the doc.
<Chuck> pk: Delighted to hear that its good timing. It's past due.
<Chuck> pk: Welcome any comments or edits from you Bruce.
<bruce_bailey> fits side discussions at Inter Agency Accessibility Forum (IAAF) earlier this week
<bruce_bailey> need to think what a post-testing paradigm might look like, and this doc supports that
<Chuck> Cybele: I haven't read the doc. Wondering if you have any initial thoughts about ways that Silver could incentivize or help with early adoption and less reactive.
<Chuck> Cybele: Taking accessibility guidance from the start.
<Chuck> pk: I do. Not sure how broadly implementable they are (not easily). When you think about a wiki, you are constraining the author such that they are not html.
<Chuck> pk: they are writing in abstraction.
<Chuck> pk: On the flip side, you can enforce a lot of things in their authoring environment to make it difficult to author a number of inaccessible things. A lot can be taken care of.
<Chuck> pk: For example, if the authoring tool doesn't allow a change of font size, but only allows a choice of styles, maybe change the look of the styles but not the font directly.
<Chuck> pk: If you are restricting the full capabilities of HTML. You can foreclose a lot of accessibility violations.
<Chuck> pk: At larger companies we see basically not allowing content to be published in raw HTML. You are restricted to that companies authoring environment.
<Chuck> pk: That's just one mechanism that could be implement.
<Cyborg> removing barriers or restrictions to full expressiveness of HTML?
<Chuck> pk: Don't see how it can work for all of them.
<bruce_bailey> Adding to what Peter is saying, I think mark-down is so much better than WYSIWYG !
<Chuck> pk: Sensory characteristics. Those techniques would not forestall the content author from making reference to color.
<Chuck> pk: But you can do a number of things in a more constrained authoring environment.
<Chuck> cyble: Is that appropriate to add to your doc? Or doesn't fit in scope?
<Chuck> pk: This first itiration is to wrap our arms around the challenges rather than pre-maturely come up with solutions in detail or directional before we are comfortable articulating the challenges.
<Chuck> pk: I'd like to do this in 2 stages.
<Cyborg> Peter: challenges without directions forward are insufficiently helpful
<Chuck> Shawn: My own experience working at this large org of Google. At IBM we would restrict the expressiveness of content in the authoring tool. Google is the opposite.
<Chuck> Shawn: 12 teams contribute raw markup, 12 different end results that are piled together. Entertwined and they affect eachother. Another dimension of the same problem.
<Chuck> pk: We had a bunch of internal discussions as seeing that as a 5th challenge. We made a couple of attempts at language. Basically the issue that...
<Chuck> pk: Large orgs are often building a site with dispirate teams that are given a large amount of independence. Weaving that all together is a challenge arrising from the size of the org.
<Chuck> Time check.
<CharlesHall> side question: is anyone in this group going to the Inclusive Design for Immersive Web standards workshop in Seattle on 11/5-6?
<Chuck> pk: I'd welcome contributions related to those challenges.
<Chuck> Shawn: If you have earlier drafts, I can bring in my thoughts.
<Chuck> pk: drop me a note.
<Zakim> bruce_bailey, you wanted to suggest that this challenges doc might steer silver
<Chuck> bruce: I think what Peter and Shawn are talking about, and how this might inform Silver. We are trying to get past the page conformance paradigm. If Silver can address these large issues.
<Chuck> bruce: This could be a huge win.
<Chuck> pk: Agreed.
<Cyborg> Bruce: production issues re: Peter and Shawn
This is scribe.perl Revision: 1.154 of Date: 2018/09/25 16:35:56 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Present: jeanne janina PeterKorn MichaelC Cyborg Lauriat Chuck CharlesHall KimD Jennison bruce_bailey Regrets: Angela JohnKirkwood Found Scribe: Lauriat Inferring ScribeNick: Lauriat Found Date: 11 Oct 2019 People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]