Meeting minutes
<alastairc> WCAG 2.2 issues [60 minutes] Survey: https://
Alastair: Survey will stay open, has 15 items associated with it.
announcements (including CSUN attendance)
<alastairc> https://
Alastair: Face to Face CSUN attendance , there are 10 people intending to be there in face to face , 6 remotely.
… please do sign up and answer if you can
… do we know timing for day?
Rachael: 8am Pacific , 11am ET through afternoon is plan, nothing definite.
<alastairc> Questions on Editor's Draft Survey: https://
Alastair: Survey on editor's draft .
Rachael: Relatively short survey. The second question was answered previously but we are carrying over. Please do submit if you are able.
Closes this Thursdsay.
Alastair: Any open announcments?
MaryJo: WCAG2ICT update . We are creating guidance for WCAG 2.1 a and aa . We have our first four ready for survey. We have background section as well.
… We will be pointing out a survey for AGWG . I'm creating survey right now. We will discuss in AGWG meeting .
<AWK> +AWK
Alastair: Might be March 21st timeframe with CSUN etc. happening.
Guideline Grouping Survey Survey: https://www.w3.org/2002/09/wbs/35422/guideline-org/
<kirkwood> +1 to AWK re more time
AWK: Plea for consistency on when surveys are open until. Thursday closings are hard time wise to respond. More time is better.
<jon_avila> I find the timing of the surveys very confusing.
Chuck: We are opening on Wednesday , then week to respond on Thursday of next week.
<bruce_bailey> i confess to struggling with new pattern as well
Chuck: hopefully that works for all, as that also helps to include weekend for chairs.
AWK: appreciate the efforts on aggregating the comments.
Alastair: WCAG 2.2 issues are backlog issues. Multiple issues , those are left open and we tackle per week. WCAG 3 is more topic based and gathering of opinions.
… Different use cases , but goal is to have more time to have to respond , Thurs to Thursday window for responses.
<alastairc> https://
Alastair: Context was to have placeholder level content and organizing for work. Organized by topic , scope, expertise. Currently placeholder only.
… more about how we are working through them, vs. how we are going to present the content in the end
CSUN is on 13th, we don't have a meeting on Tuesday, next is on March 21st.
Color Contrast, Luminescence and Text size
Alastair: Mostly comments were from Andy S.
Rachael: Andy would like to add second guideline to proposal, places in link to Google doc
… Readability and luminance contrast topic and comments may be easier in document.
… opens up to group for comments.
<Lauriat> +1 to Alastair, we'll need similar expertise, best to keep grouped.
Alastair: May be worth separating out if have enough for different sub groups . Any particular comments from group?
<Rachael> Contents use sufficient contrast and do not rely on color alone
<Rachael> Contents use sufficient contrast and do not rely on color alone
Gregg: What are we separating out?
<Rachael> Contents use sufficient contrast and do not rely on color alone
Rachael: Color alone vs. visually readable content uses sample luminance
<Rachael> Visually readable content uses ample luminance contrast
Gregg: Visually readable ... one would rely to buttons vs. text ? They should state why they are different. Running text. vs. no running text.
<Zakim> Lauriat, you wanted to +1 Alastair on context
Lauriat: Does splitting out guidance within work , that is more a question within subgroup to decide.
<GreggVan> +1
Alastair: In the document, we can leave them separated out. How we arrange the work, it would be the same subgroup. We will get back to Andy.
Rachael: I would leave the notes in the doc, I would re-word if we are to split them out. Subgroup action item.
<Rachael> +1
Rachael: Jennifer recommended putting in structure . Structure should be own subgroup ? Kind of opposite of last topic on organizing.
<ToddL> Jennifer sent her regrets via email the other day
Alastair: Jennifer not on participant list. Regrets for this meeting. For this work, we will keep in document. Subgroup can consider that topic as well.
Rachael: slightly different conversation on breaking them out. Want to avoid subgroups working on same thing in different places.
Gregg: I would agree. Making a comment on structure being consistent. Consistency around cognitive , agree separate.
Term / grouping for "safe"
Rachael: Site or app is "safe" to use. Alternative phrasing is requested. Flashing, animations, motion, etc. Need name for guidelines.
Rachael: Not dangerous was one recommendation.
<jeanne> I like "avoids known hazards"
<ToddL> I just added a comment in the doc. Suggestion: "The site or app does not cause harm"
Gregg: Working groups need to be separate. I.e. flash and computational aspects. Different expertise for other topic.
<jeanne> +1 to splitting into two groups because of different technical expertise.
<Rachael> +1 to splitting it
Jaunita: If we are talking about banking, i.e. critical errors, you have risk. For example, financial fraud, etc.
Laura: request to remove third party . We don't have consensus yet. It would be for everyone.
<Zakim> Rachael, you wanted to answer the 3rd party piece
Rachael: This pulled together the work back in the fall that was done on this topic. Warns users should still be part of what is within this topic.
<kirkwood> +1 to delete “3rd party”
Alastair: Flashing and Animations grouped together?
Todd: Guideline , the site or app does not cause harm would be one suggestion.
<jon_avila> Is there any concern that saying "warning" might make people think it's ok to use flashing content as long as they warn the user first.
Alastair: holistic term of safe vs. avoiding harm... thank you.
<kirkwood> safety & security guidelines is terminology have used
John Kirkwood: on terminology being used .
Alastair: More on subgroups to decide
Overall organization discussion
<jon_avila> I agree "safe" is different than doing no harm.
Alastair: Not being organized by principle. Jennifer wasn't convinced this was needed. Perhaps by topic, etc.
<jeanne> +1 to say that tagging will be essential and is part of the design
Alastair: editor's note on feedback , as part of this for PR for placeholder in regard to the draft structure .
<Lauriat> +1 to jeanne, beat me to noting it
Alastair: talks to it not being final, but structured by tagging vs. one particular structure in general.
Gregg: This document is for organizing outcomes. The guidelines aren't organized per se. The guidelines could still be organized in POUR principles.
<Zakim> jeanne, you wanted to say that tagging will be essential and is part of the design
Might be an interaction that the sub outcomes may not sort well if sorting guidelines.
<GreggVan> +1 to Rachael's comments
<jon_avila> I agree with the tagging approach
<alastairc> +1, I've been through re-organising the guidelines multiple times, and am pretty confident there is no "one way" that works across organisations / audiences.
Jeanne: Part of design is heavy use of tagging and flexibility of organization. We are trying to organize by topic and expertise. For a way of identifying what goes together. We aren't getting rid of POUR (principle) . Some could apply to perceivable and operable per se.
<Rachael> +1 to alastair's point
<Zakim> Rachael, you wanted to suggest alphabetical order for the placeholder level
Jeanne: Design group is working on findability and filtering of information vs. how we are working on these items.
Rachael: We do have levels, so we may not need organization . Grouping for work is important. Perhaps grouping alphabetically would be beneficial .
<Zakim> bruce_bailey, you wanted to note i marked my comment as resolved -- is that constructive to the process? Or should I let editors do that?
<GreggVan> oops I meant +1 to Jeanne's comment (also rachael now)
Bruce: Alphabetical sorting comment on organization.
… on comments, in Google doc, marking as resolved ok in document?
Rachael: Yes, that is fine.
Alastair: Jared Spool mentioned that alphabetical is arbitrary , thus true to what Bruce mentioned.
<bruce_bailey> completely arbitrary and intentionally so -- i love it
Rachael: PR is next step. Please comment in Google doc if you are able to.
Discussion about Requiring vs. Encouraging
Chuck: We know these are challenging conversations. We know they are all valid. We follow the code of ethics .
… We want to call out blanket statements and may need further research .
… we found out that framing of required vs. encouraged did not work out entirely. All are requirements for someone , somewhere.
We need to think of difficulty level of a particular method or recommendation and consider user impacts, then we map to bronze, silver and gold. I.e. needs for education and training. Healthcare. Entertainment needs, for content types.
… conversation will continue next Monday regarding mapping.
Gregg: Very good points. We talked to concept of requirable and encourage able , how does the person know that they've done it or not , passed it or not. Make it easier...how do I know if it is easy enough?
<Zakim> alastairc, you wanted to comment on trying to separate user-requirement from spec-requirement
<Chuck> https://
Alastair: I was also member of call yesterday. We have rough notes and will refine it as we move through it .
We have a slight problem , user requirements and what we are requiring in terms of the specification. We have requirements we want included. WCAG 2 isn't a complete map of accessibility related.
… spec was on what we expect authors to do. User requirements vs. requirements themselves . Mapping those to bronze, silver and gold levels.
<GreggVan> perhaps use "user needs" and WCAG requirements
<bruce_bailey> WCAG has had similar challenge with the use of the word "guidance" and "guideline"
Do we want to have a more complete listing to include?
<Zakim> mbgower, you wanted to say often we speak of "user needs" and "standards requirements". Can we maintain those perspectives?
Alastair: Are we prepared to do that? We need to concentrate on required , due to MVP requirements of charter.
Michael: User needs vs. standards requirements may be a possibility
… my need may be more general, requirements may change and be different.
<kirkwood> agree with user needs separation
<bruce_bailey> yes, requirements of the requirements we are crafting
Alastair: Requirements of spec vs. author and user needs as well.
Gregg: Plus one on user needs. If in WCAG 3 , user needs and what we can do to meet them. Some are required , some are not. Requirable vs. encouraging (recommendations) .
<Zakim> Rachael, you wanted to say next steps
Rachael: These are two meetings that are setting up the face to face conversation. We will revise the two options and bring this back to group on 13th as a subgroup back to AGWG
Alastair: We will talk to this more in CSUN remote and Face to Face discussion
agreed: )
<Jennie> *I would really appreciate an email to the list, a week ahead of the CSUN hybrid session, with links to any documents that will be discussed.
<Rachael> Jennie, we will do our best
<Chuck> +1 Jennie
WCAG 2.2 issues [60 minutes] Survey: https://www.w3.org/2002/09/wbs/35422/wcag22-misc5/
<Jennie> *Thank you @Rachael!
Alastair: Agenda moves toward WCAG 2.2 issues
1. Suggest more structure to Intent section of 3.3.7 Understanding article #2650
Alastair: most people agreed , one suggestion with adjustment, editorial changes. Opens to Michael.
<jon_avila> Agree with Mike!
MikeG: Is there something as fully inclusive and accessible? Perhaps "more" accessible or inclusive. Perfection is concerning.
MikeG: Suggestions were more editorial in survey.
<kirkwood> +1 to MG issue on “fully accessible”
<bruce_bailey> +1 to MG edit for "more accessible" versus "fully accessible"
<GreggVan> +5 to that. we even devote a paragraph to saying nothing is ever "accessible"
Alastair: Link was to accessibility enhanced.
<GreggVan> only better or minimum
<alastairc> Line 63 - change from fully to 'more'
MikeG: talks to granularity of line 63 on issue
<bruce_bailey> https://
MikeG: Other suggestions were editorial in nature.
… my hope was not to changing in meaning.
<kirkwood> ho about just getting rid of the “more” or “fully” qualifiers?
<AWK> https://
Gregg: if you are talking about "the web" it is capital. If website, it typically is not capitalize it. Defer to W3 definitions and editorial aspects.
<GreggVan> +1 to that
Alastair: Want to avoid massive find and replace regarding where this is mentioned.
<alastairc> draft RESOLUTION: Accept PR 2988 with adjustments from mbgower
DanB: The original issue was consistency around organization. Not sure if separate concern of what PR is resolving the issue.
<bruce_bailey> From https://
<bruce_bailey> Either capitalize or lower case "Web" (e.g., Web developer or web developer, Web project or web project, Web page or web page, Web application or web application
Alastair: I thought it did resolve the issues.
<bruce_bailey> Web site, web site, website : two words (capitalize or lower case "Web") or one (lower case)
DanB: I was referencing 2650 PR.
<alastairc> draft RESOLUTION: Accept PR 2988 with adjustments from mbgower, double-check that it answers issue 2650
Alastair: I may need to reference the PR and answering the questions contained
<Ben_Tillyer> +1
<mbgower> +1
<GreggVan> +1
<Wilco> +1
<ToddL> +1
<dan_bjorge> +1
<Jaunita_George> +1
<bruce_bailey> +1
<Makoto> +1
<AWK> +1
<kirkwood> +1
RESOLUTION: Accept PR 2988 with adjustments from mbgower, double-check that it answers issue 2650
RESOLUTION: Accept PR 2988 with adjustments from mbgower, double-check that it answers issue 2650
<Laura> +1
3. Example Could Be Replaced with an Example that Encourages Greater Equity #2550
<alastairc> https://
Alastair: Color wheel topic and inputs around using it.
<ChrisLoiselle> thanks, Bruce!
Michael Gower: I think concern Suzanne raises in survey has been addressed.
[MG quotes color wheel excerpt]
mbgower: Per my comment in survey, I think it redundant
<alastairc> A widget where you can drag a gift to one person in a photo of a group of people also has a menu alternative where users can select the person that should receive the gift from the menu.
alastairc: Everyone agreed, so question is do we add example?
… please +1 to add example , or -1 if you think it redundant
<mbgower> -.1 especially because it's a little hard to picture/understand
<alastairc> Poll: +1 to include, -1 to not include
<Chuck> bruce_bailey: Is one of those drag and drop?
<GreggVan> +1 to have a drag and drop
<Chuck> bruce_bailey: The other's didn't sound as much.
bruce asks if earlier example is clearly drag and drop ?
<dan_bjorge> +0.5 - I think it's redundant with the existing 3rd example, but better than the existing example (ie, drop the 3rd)
bruce: slider control is not great example of drag and drop
greggv: i think we should keep both because there are so many kinds of drag-and-drop
… the example with coordinate entry seems not similar to others
<GreggVan> +1 to that kanban is jargon
dan_bjorge: i think 3rd example IS drag and drop, but its not obvious
… so I suggest replacing that one with this simpler example
alastairc: I recommend keeping that one in, as it is a common pattern...
<dan_bjorge> Also fine with keeping both if the 3rd is really a specifically common example in practice
<alastairc> A kanban implementation allows users to drag and drop items between columns, and provides an additional pop-up menu after tapping or clicking on items for moving the selected element to another kanban silo by tapping or clicking on pop-up menu entries.
alastairc: Trello is drag and drop for example , but keyboard alternative has good useabiltiy
alastairc: How about updating Kanban example ? And keeping others as well?
<Laura> +1 to Gregg
GreggVan: For interests of plain language, can this be writting without out "Kaban" and describe functionality.
<GreggVan> +1
<dan_bjorge> "task board"
<kirkwood> no
<alastairc> A task board (kanban) implementation allows users to drag and drop items between columns, and provides an additional pop-up menu after tapping or clicking on items for moving the selected element to another kanban silo by tapping or clicking on pop-up menu entries.
MikeGower suggest Kanban in parenthetical -- because it is useful for people who know the term
mbgower: i will have suggestion in PR comment
<mbgower> A taskboard that allows users to drag and drop items between columns, also provides an additional pop-up menu after tapping or clicking on items for moving the selected element to another column by tapping or clicking on pop-up menu entries.
ChrisL gives a technical definition.
alastairc: So we will include Detlevs updates and some of thees other suggestions.
<kirkwood> “drag and drop task board"
[alastair does some screen sharing with PR edits]
<kirkwood> oops
<ToddL> "signboard"
<alastairc> draft RESOLUTION: Accept PR #2753 with amendment to link to taskboard / kanban explanation.
alastairc: To Jon A, suggesting is okay but already addressed in full context.
<kirkwood> +1
<ToddL> +1
<Wilco> +1
<Ben_Tillyer> +1
<Makoto> +1
<dan_bjorge> +1
RESOLUTION: Accept PR #2753 with amendment to link to taskboard / kanban explanation.
<Laura> +1
<Raf> +1
4. Focus not obscured margin technique and working example #2746
<Jaunita_George> +1
alastairc: This is new technique because we did not have clean example previously
[alastair review comments from survey]
https://
alastairc: From preview, I have incorporated suggestions from survey.
… still needs a little more work and suggestions to better address Wilco's suggestions.
… we might be able to trim back , deleting CSS in example
<alastairc> Updates: Ensure it works at different viewport sizes.
<alastairc> ... reduce amount of code in example (rely on the working example)
alastairc: i am checking sample code with different view ports sizes
<alastairc> ... Update test procedure to clarify the tabing-to aspect, not scrolling plus tabbing.
alastairc: Other updates to techniques?
alastairc: Okay to leave to Francis to pull and minor edits?
Wilco: Concur.
Francis Stor: There was a suggestion about useability with code highlighting...
[alastair and francis discus]
<alastairc> draft RESOLUTION: Accept PR #2746 with proposed amends to be done.
<Laura> +1
<Wilco> +1
<ToddL> +1
<kirkwood> +1
<Chuck> bruce_bailey: Make sure that you aren't counting on me to make notes Francis...
alastairc: This is still an issue for FireFox
<alastairc> Also check Firefox, not fixed element
RESOLUTION: Accept PR #2746 with proposed amends to be done.
5. What are the user's solutions of Focus Not Obscured (minimum)? #2700
https://
alastairc: Propose essentially we accept Detlev response on GitHub thread.
mbgower: I am not sure we got the question. I was not clear if after focus on not wrt person who submitted issue.
… i am note sure if response is complete
<Jaunita_George> +1
alastairc: i will add in your comments from survey
<alastairc> https://
alastairc: Detlev reply are examples on solutions for some points raised by commenter...
<alastairc> draft RESOLUTION: Accept Detlev's response to the question, as amended.
alastairc: MikeG is more from developer perspective
<mbgower> +1
<Chuck> +1
<dan_bjorge> +1
<Laura> +1
[no objections raised]
RESOLUTION: Accept Detlev's response to the question, as amended.
<kirkwood> +1
<Makoto> +1
6. Clarification sought on "set of web pages" #2298
<ToddL> +1
https://
https://
alastairc: We have added a few more examples and clarified another...
… substantial comment from Wilco, recommending against change to any TR doc
alastairc: If keep to Understanding docs only , this will be 5-6 success criteria -- so a number to update
MikeG: are example in spec normative or informative ?
<dan_bjorge> From 5.1, "Introductory material, appendices, sections marked as "non-normative", diagrams, examples, and notes are informative (non-normative)."
alastairc: nominally examples are informative , but still effects translations
Wilco: Change in TR space remains problematic, not just for translations. We have to resolve for 2.1 or 2.0 as errata or not?
… not understanding rational for keeping to Understanding.
<alastairc> Poll: Include example in (1) The definiton, or (2) the five understanding documents
alastairc: Updating definition for 2.2 seems much cleaner. Does answer for 2.2 only change voting ?
GreggVan: If it is definition, then normative ?
alastairc: Examples in definition are informative.
<GreggVan> +1 to Mgower
mbgower: It is a good place to have definitions clear , as technology matures
<jon_avila> I don't have strong feelings either way.
<kirkwood> +1 to MGower
Wilco: It is not just this case only, there are endless place we might make things clearer. Adding examples as technology evolves seems unending.
alastairc: We addressed this with 2.2 on similar issue that Jon Availa raised. We have space with 2.2 to add some clarity...
… We would not anticipate errata for 2.2 just to add an example....
<Zakim> mbgower, you wanted to say changes https://
alastairc: this is for publication. After publication is a very different case.
mbgower: Process question, are edits in GitHub constructive -- or should I stick with survey?
mbgower: explains mechanics of suggestion on pull request for suggested edits to PR
… Is that something to avoid? Should I use survey only?
<GreggVan> Good for accuracy. Color visions is not required --
alastairc: As chair (editor) the suggestion mechanic is VERY helpful.
<Zakim> GreggVan, you wanted to say Agree we don't want to do this a lot -- but we should do when WE think it is unclear or we need to clarify with our own team
alastairc: Would ask for as soon as possible, make reference to survey.
… no need to repeat PR suggestion in Survey
GreggVan: The fact that we are making examples for each other is telling that we need better examples.
<alastairc> Poll: (1) Update in the definition, or (2) add the examples to the Consistent Help SC understanding page.
alastairc: Agreed, and this example cam from jon_avila who is on the call.
<GreggVan> 1
<dan_bjorge> 1
<Ben_Tillyer> 1
<mbgower> 1
<Wilco> 2
<Jaunita_George> 1
<Chuck> 1
<kirkwood> 1
<Makoto> 1
<jon_avila> 1 but either way would work
<Laura> 1
<ToddL> 1
<mbgower> I'd prefer just 2.2
Wilco allows group consensus
defers
<Wilco> prefer errata for both
alastairc: question as to what to do for 2.1 , 2.0 ?
<alastairc> Poll: (1) Supplement defintion for 2.2 only (2), or include as errata for 2.1 and 2.2
<mbgower> prefer 1, but 2 is fine
<alastairc> Poll: (1) Supplement defintion for 2.2 only (2), or include as errata for 2.1 and 2.0
<GreggVan> 2
<jon_avila> 1 but 2 would be fine as well
<Ben_Tillyer> 2
<Makoto> 2
<ToddL> 2
GreggVan: Updating definition is going to raise red flaggs, so please characterize as "supplementing current definition"
<Rachael> 2 but 1 is fine as well
<Laura> 1
<Wilco> 2
<Jaunita_George> 2
<dan_bjorge> either fine
<Laura> no objection
alastairc: Any objections on call for doing as erratta ?
<Jaunita_George> We probably should keep guidance consistent and the errata would help us do that
alastairc: One other suggested example from MG ...
<alastairc> Any issues with the suggested update?
<kirkwood> +1 to suggested update
alastairc: Any problem with this update from MikeG?
<dan_bjorge> +1
<ToddL> +1
<mbgower> +1
<Makoto> +1
<Ben_Tillyer> +1
<Laura> +1
<Jaunita_George> +1
<Rachael> +1
RESOLUTION: Accept PR #3008 and add as errata to 2.0 and 2.1
<jon_avila> +1
<Wilco> 0
7. Dragging Movements - Carousels - Overflowed Containers #2684
mbgower: Have another words smithing
https://
<jon_avila> Scrolling feels more like a gesture
alastairc: Concern is that scrollable containers are not in scope of dragging.
alastairc: Asks if MikeG has incorporated into his PR suggestions?
<jon_avila> Not all scrolling areas have scroll bars.
<jon_avila> Firefox will add tabindex to areas with overflow - but other browsers will not.
mbgower: I did not , as I thought that was changing PR too much
alastairc: I suggest we accept PR, as we can investigate and ammend later if needed
<alastairc> draft RESOLUTION: Accept PR 3040 and close issue 2684
<Ben_Tillyer> +1
<mbgower> +1
<ToddL> +1
<Wilco> +1
<Makoto> +1
RESOLUTION: Accept PR 3040 and close issue 2684
8. Update focus-appearance
alastairc: Minor edit from Wilco
mbgower: i have in my PR
<alastairc> draft RESOLUTION: Accept PR 3017
dan_bjorge: Distinction between WHILE keyboard focus versus when RECIEVING kb focus
mbgower: This is focus , not focus unobscured
alastairc: SC did get slightly tweaked, lets double check
mbgower: We have current requirement for focus indicator , and the SC for focus visible versus focus
<alastairc> draft RESOLUTION: Accept PR 3017
<Wilco> +1
<Laura> +1
dan_bjorge: this prose is illustrating and contrasting SC , so we should be careful
<mbgower> +1
<ToddL> +1
<Rachael> +1
<Ben_Tillyer> +1
<Makoto> +1
<kirkwood> +1
<GreggVan> +1
RESOLUTION: Accept PR 3017
9. Does Redundant Entry require the data available in the current step? #2805
https://
alastairc: For context, earlier version of SC includes series of steps -- and that was problematic
<alastairc> Requiring people to recall information entered previously can cause them
alastairc: this PR updates Understanding to match current SC text , and having mention of steps was confusing
… survey question might have included some of that context , which address Wilco's comment in survey.
mbgower: I have provided editorial suggestion for some of this
alastairc: Comment in survey from jon_avila about in the same page -- addressed by fact that SC scoped to page
dan_bjorge: In context in this SC, can we add "in the same process" ?
alastairc: The "same process" might reference data from three screen prior -- so that is not as helpful.
<alastairc> Data which is "available to select" would need to be on the same page.
<jon_avila> I agree with the idea - thanks for the clarification
[alastair and wilco discuss less-jargon phrasing]
[mbgower explains UI option for line-by-line comment/suggestion]
<alastairc> draft RESOLUTION: Accept PR 3042
<alastairc> draft RESOLUTION: Accept PR 3042 as amended in the PR
<jon_avila> +1
<Laura> +1
mbgower: Page icon with plus symbol , very mouse centric operation , but converts your entry to suggestion which is easy to add int
<Chuck> +1
<mbgower> +1
<Wilco> +1
<kirkwood> +1
<jon_avila> Thanks all
<Makoto> +1
<mbgower> Thanks all
<Rachael> +1
alastairc: More questions for next week!
… we got through 8 of 10 hightlighted
zakim ?