Meeting minutes
<Lauriat> Where to sign up to scribe: https://
<sajkaj> https://
Janina: There is an upcoming symposium, research papers are invited. Please review this link for details.
Shawn: thank you, looks very interesting
Bruce: Can you share Web page announcement?
<jeanne> https://
<sajkaj> https://
Guideline drafts in the migration outline working session
<bruce_bailey> thanks, that coop page was the one I saw yesterday and was thinking of as we talked
<bruce_bailey> https://
Shawn: I wanted to walk folks through the outline map. This link goes directly to a location that is a little cleaner. The exercise is to write rough guidelines to show the general format for WCAG 3.
… I added 3.1.1 and 3.1.2 Language of page and language of parts
… these could be seen as just part of using HTML correctly, according to spec
… Sara has added some user needs related to errors, and the guideline itself as error prevention.
… it is possible links might be grouped with error prevention, given similarities with adding a helpful label
Wilco: We are working on tests for language of page and language of parts as well
<sajkaj> https://
Janina: noting that we want to point out the purpose of a link and things like that, APA is going to candidate recommendation in a very predictable way, that browsers will pick up.
… not only can we support identifying purpose of links, but we can also translate among AAC symbols sets (for COGA)
<bruce_bailey> happy to help, it has a been long time since I used bliss
Shawn: Moving up in the outline, there is error identification and error notification, I left those as is, since Sara had already drafted those.
<Lauriat> User need(s) - Consistency in menus and navigation benefits people with cognitive impairments and people who are blind. Consistency in the access to navigation is also important. Consistency in interactions with components is also important. Task-based assessment will be important here.
Shawn: The grouping above that is Consistent Nav, Consistent Identification, and Concurrent Input, and target the user need I just pasted in
<Lauriat> Guideline: Provide similar structure and functionality via consistent paths & interactions
Shawn: I added a drafted guideline for this ^
<Zakim> jeanne, you wanted to ask about Jake's proposal?
Jeanne: This is great. Delighted you are working on this. Wondering if you have considered Jake's proposal with this?
Shawn: Definitely. I began with this, but thought drafting the guidance was an important step in moving forward with trying Jake's structure. And working on the user needs mapping is also on the agenda for today.
… thought is we can take the concrete guidance and then map that into Jake's structure
Shawn: The next group above that is 3.2.1 3.2.2 and 3.2.5. This one didn't have user needs listed, but did have methods.
<Lauriat> When any user interface component receives focus, it does not initiate a change of context.
<Lauriat> When the user interacts with a component, context remains the same.
<Lauriat> Warn the user that context will change when they interact with a component.
<Lauriat> Only change context on user request.
Shawn: I boiled this down to a guideline to hopefully cover all of the types of focus: e.g. keyboard, AT, cognitive conceptual
<sajkaj> +1 to cognitive focus -- good catch!
Shawn: something to test out and see how it works
Shawn: Are there any comments on the over-all level of detail at this stage, without wordsmithing
… we are aiming to give a sense of the overall structure that WCAG 3 will likely have
… with the understanding that it will change significantly
Leonie: As someone who has been watching from a distance, this does look like a good way to move forward
<sajkaj> +1 to getting the overall structure before worrying too much about details
Jeanne: This is also in response to a request for an overall view from AGWG
Shawn: Moving up again in the document, there is pronunciation, reading level and abbreviations
<Lauriat> User need(s) - ambiguous interpretation of words. Does it also apply to speech input? Would this apply more to people who are deaf, whose words may not be easily understood by machines. Speech as a mode of input should be linked to Pronunciation, so that people don’t have to look in two places. (example: read, read, red)
Shawn: user need is to provide the correct pronunciation when that impacts meaning
<sajkaj> https://
<Zakim> sajkaj, you wanted to note APA Pronunciation TF work
<bruce_bailey> another favorite example of mine is wind the watch versus the wind blows
janina: APA is hoping that by the time WCAG 3 is ready for CR, this specification will be in play
<Makoto> SC 3.1.6 was originally from proposals from Japan. Kanji characters can have multiple ways of reading.
Jeanne: my understanding was that this was not oriented toward speech input, but was oriented toward COGA, should we add speech input?
<Lauriat> Guideline: Augment text with ways to better understand it
<Zakim> tink, you wanted to ask about intenationalisation
Leonie: How English-specific is this? Do all languages have these?
Shawn: They all have their different systems and it is definitely going to get complicated as we explore different languages
<jeanne> q+ to talk about clear words and international plain language
Janina: I know COGA is very interested in this and is working on updating the Content Usable document on clear words and plain language. There are significant issues as we move into different languages.
<Makoto> "SC 3.1.3 Unusual Words" was also originally came from a proposal from Japan.
<Zakim> jeanne, you wanted to say this was intended to be more COGA oriented than speech input oriented
Janina: but it is important to say what we need to without letting internationalization issues prevent us from providing the guidance that we can
Jeanne: There is a group in the EU that is working on clear language across languages as well
<Lauriat> Original user need description for this grouping: both Unusual words, abbreviations or acronyms need to a way for users to understand the meaning of words in their context. Language barriers are also served by this. How literal a word is in context is also an issue for people with cognitive disabilities.
<bruce_bailey> I can never remember the word for words that can be pronounced different: homograph
<bruce_bailey> https://
Jeanne: we can tap into that work
Shawn: The overall guideline itself points in the right direction. It is trying to say that regardless of how things are written, it is good to have a way to augment that text with added info to make it more understandable.
… one example is abbr
… another is a Mac short cut to show pronunciation and definitions for words
Shawn: We have not yet incorporated WCAG 2.2 yet
Jeanne: Can reading level go in with pronunciation?
Shawn: Perhaps, but one is more about augmentation and the other is more about authoring
<bruce_bailey> lol, that was wrong. the word I was looking for is heteronym or heterophone:
<bruce_bailey> https://
<Lauriat> SC 2.5.6 Concurrent Input Mechanisms User need(s): variety of inputs, may switch between inputs at any time. See if there is overlap with pointer cancelation
Shawn: Next is language of page and language of parts which I moved to use HTML correctly
Shawn: Above that is SC 2.5.6
<Lauriat> Guideline: Allow users to switch input modalities mid-task.
Shawn: moved what had been a method up to the guideline level
How we might incorporate the User Needs Vs. Functional Needs mapping structure
Shawn: At this point, I wonder if we have talked through enough examples to pivot to focusing on the structure Jake proposed and see if we can merge the 2
^ link to Jake's spreadsheet
Shawn: In column 1, you will find user needs, grouped by core principle, such as "Operable"
… Let's choose one guideline as an example. "Allow users to switch input modalities mid-task" can go where "Operable" rows intersect with the "Mobility" columns.
… The sense I'm getting is that this structure can help us see how well we have covered the intersection of user needs and functional needs
<bruce_bailey> i concur with that observation
Shawn: more so than a structure that will be part of the final structure of WCAG 3
… Jake's structure will be a internal tool
Jeanne: I agree. But I'm a little disappointed that this is not a shortcut to outcomes.
… it is more of a more thorough way to track user needs
Bruce: What is the core question?
<jenniferS> Perhaps check the transcript for the question?
Shawn: The question is do you agree that Jake's spreadsheet is an internal tool to ensure coverage?
Jeanne: In many ways the guidelines are becoming context topics
… I mean this as a question
<MichaelC> In review in Functional Needs group, I proposed the guidelines be renamed as user needs
Shawn: Are there other things that we can use this for. The original intention was to produce outcomes.
Shawn: Does that mean that this would have been Guidelines versus Functional Needs mapping?
<Zakim> bruce_bailey, you wanted to note that this SS definition for essential does not much overlap with WCAG 2.x use of that word
Shawn: Most guidelines will span user needs, so User needs won't work well as a top-level structure
<MichaelC> I plan to experiment with some slicing and dicing of the structure, via the database I´m developing, and see if it yields insights
Bruce: The definition of essential as, "without physical harm or risk" conflicts with WCAG 2's use of "essential"
Shawn: Agree, and I had been thinking of essential as simply "essential to what the user wishes to do" such as make a purchase
Shawn: From here my thinking it we can continue to go through the Outline Map. Continue to compose short term placeholder guidelines. Then it might make sense to take the spreadsheet and place those placeholder guidelines in the spreasheet to see both coverage and other uses for the spreadsheet
Shawn: Other next steps? What is the best way to plug the placeholders into the editor's draft
CFC for Explainer
Jeanne: We can design a unique format to make it clear that these are placeholders. I can work with Mike on that
<MichaelC> Will work on a dedicated entry mechanism as things mature, and I get tools build
Jeanne: Please check your email and please vote (for or against) on a paragraph of the editor's note, this is the last step before approving publishing the Explainer.
… be sure that you are replying to both lists when you vote
… make sure it goes to both AG and Silver lists
Janina: What is the deadline?
<jenniferS> 13th
<jeanne> https://
<jenniferS> Wednesday September 15th at 10:00am Boston time. (sorry!)
Sign up to scribe!
<Lauriat> https://
Shawn: Please sign up to scribe
thx!
make it more understandable.
rssagent, make minutes