<Wilco> scribe: Wilco

Alastair: Would anyone like to introduce themselves?

<AWK> +AWK

Jemma: My nick has changed, it's "Jem"

WCAG 3 Scoping https://github.com/w3c/silver/milestone/12

Alastair: We have quite a few issues against the scoping milestone.

<mbgower> https://docs.google.com/presentation/d/1xi6yp4eXSlhIONFVeCqiq7jVbif8yP1w/edit?usp=sharing&ouid=118419493369958965106&rtpof=true&sd=true

Mike: I've made a basic presentation I'll walk through. Link above to Drive
... A few of us have been working on scoping conformance.
... It's good to have a discussion as we're working towards solution, as opposed to proposing the solution.
... Work on considerations with us.
... On slide 2 we tried to define a problem statement.
... It might be worthwhile to take the reading of the group if we don't need to rethink conformance.
... Slide 3; Silver has defined conformance between levels, and process & Views
... There are definitions of process and of view (slide 4)
... The 2.x definition is quite a bit longer.
... Where it get interesting is the 2.x examples.

<alastairc> JF - I'll let Mike get through first, it will help manage the Q if people include a topic. E.g. q+ to say that...

Mike: The second example is completing a Turing test, which is quite different from the first example.
... Trying to nail down process needs to happen in a big way.
... Slide 5 has the definition of View. The first paragraph having the definition, and the second more of an explanation.
... I think that's relatively similar to how I think of DOM being loaded in a user agent.
... Who interprets what a view is?

JF: Scoping process further, I can envision a complex form which may or may not be part of the process depending on individual users.
... How to account for things that may not be there for all users but are nevertheless part of the process.
... It leverages into defining the view. The use case was progressive disclosure of help on demand. 90% may not use such a feature, how does it fit into the process?

Alastair: I've put it down as a topic.

<Zakim> Jennie, you wanted to ask about view in magnified state

Jennie: When you're discussing view, it's at 100% for magnification, and beyond is not part of the view, correct?

Mike: I've so far just read what's in FPWD. Is a view modified through assistive tech, or is it the unmodified presentation.

Jennie: Correct.

Detlev: Another example would be a shopping site with the main process, but below that a rating for the product. It's not essential to the process, but should it be considered part of the view?

<Jem> good question, Detlev.

<Zakim> JF, you wanted to ask about "how to document"

JF: On the definition of view, the tester determines the view, where and how does a tester describe the view?

Alastair: This is not a proposal yet, just highlighting the challenges.

Mike: There were quite a few responses on the question of if processes should be the smallest unit.
... The FPWD doesn't actually mention this though. That's one of the things we've discussed.
... Overall the idea that process testing was received fairly positively.
... One question was is a process actually a smaller unit then a page or view.
... Sometimes those are the same. But often even a simple process stretches across multiple views or pages.
... Complex processes inevitably span multiple views.
... Sometimes it's debatable, for example is a login a separate process.
... It depends on the granularity of the process.

<Zakim> Rachael, you wanted to say that a single page app can include multiple processes

Rachael: From the traditional definition of a page, a page can see multiple processes?

Mike: Yes
... The primary issue is what constitutes a process. Is there a way to asses that based on what views are used most often.
... There are different kinds of processes. If we're talking about user process, it helps to specify that.
... We started looking if process and view are complementary. You have a series of pages, and a process is effectively a horizontal across those pages.
... But then sometimes a page is a single application. The process ignores what's happening technologically, it assesses the user experience.
... Perhaps pages tend to be easier to test by machine, on the other hand process tends to be more about user succes.
... Slide 11; First it's important to distinguish between development process and user process.
... We started looking at a taxonomy. Slide 12 has examples of this.
... We have processes and sub processes. For purchase; add to cart, choose an item, etc.
... If we begin defining these processes, maybe we can provide examples.
... There were a lot of reporting-specific comments. How can someone ensure that processes are accurate of what's required.
... We're digging now into comparing what machine testing can do vs what manual testing can do.
... If you tested against a page, it's effectively equivalent to 2.x. Whether it must pass is a separate conversation.
... Building on top of that could be built process completion tests.
... As a third you could consider user acceptance testing.
... Slide 15; Shows how these can be stacked. On top of machine testing could be qualitative manual testing.

<Rachael> Does "machine testing" here mean fully automated or also include machine augmented with user judgement?

Mike: Finally you could complete user testing.

<Zakim> alastairc, you wanted to ask if we could/should separate guidelines by unit of conformance?

Alastair: This is an overview of the problem space and what issues have been raised.
... Chair hat off; It sounds like it would help if we could categorise the guidelines by these levels.

Rachael: This group meets on Wednesdays, e-mail me if you'd like an invite or have thoughts.
... Our next steps are to take thought and come up with a revised proposal.

<alastairc> Potential topics:

<alastairc> - Is the WCAG 2 model ok?

<alastairc> - Definition of process, WCAG 2.x included a 1-page thing which seemed odd.

<alastairc> - What about optional steps in a process?

<alastairc> - Definition of view,

<alastairc> - What about optional steps in a view, progress disclosure?

<alastairc> - E.g. rate this product, a non-essential part of the process.

<alastairc> - What about magnified, does a modified view count?

<alastairc> - Reporting

<alastairc> - What should be the unit of conformance? Was once stated as complete processes.

David: Is this a time to ask about the direction?

Rachael: Don't think we have time in this meeting, but send an e-mail with additional thoughts

WCAG 3 Requirements https://www.w3.org/2002/09/wbs/35422/WCAG3_requirements/

<alastairc> https://www.w3.org/2002/09/wbs/35422/WCAG3_requirements/results

Alastair: The first issue is about a "do no harm" there was broad agreement of it as a principle, but not sure about it as a requirement which needs to be measurable.

<alastairc> https://github.com/w3c/silver/pull/586/files

Alastair: Based on that Rachael created PR 586, and a draft response.
... [reading responses]

Sarah: He proposed a change to the design principles, and a corresponding change to the creation process.
... Will we do that?

Rachael: I didn't consider that part, lets spin off a separate issue for that.

<alastairc> q/

Gregg: If we adopt this principle, do we eliminate the contrast provision?

Alastair: I don't think so. I did have a comment back. Contrast can be conflicting, but in WCAG it defines a minimum, not a maximum. It doesn't create a conflict.
... I don't think the current approach to contrast conflicts with the new design principle.

Gregg: High contrast makes it harder for people who wants low contrast.

Alastair: I personally would disagree that this example conflicts.

<JF> +1 to Gregg

Gregg: Almost all of the cognitive will be better for some and worse for others.

<kirkwood> disagree with that assumption

Gregg: It sounds like a good principle, but it would be good to explore our guidelines and see whether they could be worse for.

<kirkwood> regarding cognitive

Alastair: We discussed this last time, that's why it won't be put in the requirements.

David: We have that example in physical, it took a while for us to get to the compromises.
... What if we say we try to minimise the effect on other disabilities.

<Rachael> I created https://github.com/w3c/silver/issues/587 so we can address updating the creation process separately. Thank you Sarah for pointing that out.

<alastairc> Preview of principles: https://rawgit.com/w3c/silver/do-no-harm/requirements/index.html#design_principles

David: Just having the principle we don't proceed on something. I wouldn't want to word it in a way to discourage us from going down a path.

JF: Work around personalisation, the idea behind it is that we'll facilitate users to customise their interaction. On the surface "do no harm" is an easy statement to support, but anything that's overly restrictive I have concern around.

Alastair: I think this is something we've implicitly done as part of consensus.
... For me I thought it was reasonably straight-forward as a design principle.

Gregg: What is the design principle? Are these general guidance, or are they rules to follow?

Alastair: These are based on requirements of WCAG 2. It's things like supporting wide range of disabilities.

<Chuck> aspirational?

Alastair: The kind of high-level what we aim to do.

Gregg: Maybe we need to say minimum adverse effects, something like this.
... if it's "should" i guess we can be okay with it.

Alastair: It's in the more aspirational section of the document.

Rachael: We had determined we wanted this last time, we're down to worth smithing.

Alastair: One more response from Mary Jo.
... There is a discussion there on how that design principle is achieved. Could be personalisation, site settings, user agents.
... It helps that Silver is more focused on outcomes.
... The next step is whether we accept the PR.

<alastairc> "Not reduce accessibility for people with one type of disability in order to improve accessibility for people with another type of disability."

<alastairc> draft RESOLUTION: Accept PR #586

<Chuck> +1

0

<Rachael> +1

<mbgower> 0

<JakeAbma> 0

<alastairc> +1

<sarahhorton_> 0

<Jennie> 0

<Detlev> 0

<ThompsonS> 0

<laura_> 0

<Ryladog> 0

<Rain> 0

<JF> I accept the idea of the principle, while remaining concerned about implementation in practice

Sarah: I think it's something we can resolve. The others are all statements about what they should do, rather than what they shouldn't do.

<alastairc> perhaps something like "improve accessibility for people with one disability, without negatively impacting people with another type of disability."

Sarah: It sounds as if this sounds something guidelines will never do. Some of the concerns were around that. It's a great principle, but hard to do. We need process to support that.

Alastair: The other design principles need processes behind them as well.

JF: Agree with Sarah. Do no harm is easy to support, but at the end of the day, no matter how hard we try we can't make content accessible to absolutely everyone.
... Putting this as a definitive statements I don't think we'll be ever successful at meeting that goal.

Alastair: That's similar to other design principles. All things to strive for.

Chuck: More 0's than 1's. I recommend this needs more work. Lets keep working it and bring it back.

<Zakim> mbgower, you wanted to say it is not within the control of authors alone; basically impossible to achieve, IMO

<shadi> +1 to Chuck

Mike: Even within one type of disability its very difficult to meet this. Just think of screen readers, some users want a lot of detail, others do not.

Alastair: This is why it's moved to the design principles.

<AWK> +1 to avoid or minimize

Gregg: Maybe using the word "avoid", it's a little less final. Or better yet "minimize".

<Rachael> improve accessibility for one functional need while avoiding significant negative impacts on people with another functional need or needs.

<alastairc> "improve accessibility for people with one disability, and avoid negative impact on people with other types of disability.

<JF> +1 to Gregg

<shadi> +1 to Gregg

<Zakim> Chuck, you wanted to ask for scribe change at top of hour

<sarahhorton_> I can scribe

<alastairc> scribe: sarahhorton_

<scribe> scribe: sarahhorton

<alastairc> scribe: sarahhorton_

<Zakim> Rachael, you wanted to ask about alastairs proposed wording before we move on?

<Rachael> improve accessibility for one functional need while avoiding significant negative impacts on other functional need or needs.

<Chuck> +1

Rachael: Does this address concerns?

<AWK> As it is aspirational I'd suggest even removing "significant"

<ThompsonS> +1

<AWK> +1, +1.25 without "significant"

Wilco: Doing this already, group knows how to balance, not against

<jaunita_george> +1 to wilco

<Rachael> improve accessibility for one functional need while avoiding negative impacts on other functional need or needs.

<mbgower> "improve accessibility for functional needs while avoiding negative impacts on other functional need or needs."

<AWK> odd grammar at end

<mbgower> avoid "one"?

<Rachael> improve accessibility for functional needs while avoiding negative impacts on other functional needs.

<JF> +1 to Gregg and AWK - concern over the term significant

Gregg: Substantial/significant not objective, can proceed

JF: Can only minimize, can't avoid

<AWK> "avoiding or minimizing"

<AWK> sometimes you can avoid

<mbgower> improvements for any functional need will avoid or minimize negative impacts on other functional needs

Gregg: Yes avoid, example of color contrast needs differ

alastairc: Aiming to avoid

<Rachael> It doesn't fit the structure of "Accessibility guidelines should:"

<AWK> provide requirements to address functional needs, while avoiding or minimizing negative impacts on other functional needs

<Jennie> Ensure that improvements?

JF: Adding requirements, expected outcomes, subjective whether improvement

<mbgower> AWK's looks pretty good

<Rachael> +1

<Chuck> +1

<mbgower> +1

<bruce_bailey> +1

<Rachael> this is a design principle not a requirement

bruce_bailey: Sometime confusion about requirements for developing requirements and final requirements, veering into latter

<Zakim> Chuck, you wanted to share rachael's observation

<mbgower> provide designs...

Chuck: Not a requirement, design principle

<mbgower> "provide designs to address functional needs, while avoiding or minimizing negative impacts on other functional needs"?

<alastairc> "provide requirements to address functional needs, while avoiding or minimizing negative impacts on other functional needs"

alastairc: Concern with latest suggestion?

<Chuck> draft RESOLUTION: Accept amended PR #586

+1

<jaunita_george> +1

<AWK> +1

<JF> +.75

<ThompsonS> +1

<Wilco> 0

<laura> +1

<kirkwood> +1

<Zakim> mbgower, you wanted to say does it help to swap in designs?

<JakeAbma> +1

<alastairc> https://rawgit.com/w3c/silver/do-no-harm/requirements/index.html#design_principles

<Chuck> sounds strange, not a fan

mbgower: Swap out designs for requirements?

<Rachael> https://rawgit.com/w3c/silver/do-no-harm/requirements/index.html#design_principles

<Jennie> +1

<JF> -1 to swapping to designs

RESOLUTION: Accept amended PR #586

<Rachael> PR is ammended.

Scope of Guidelines #326

<alastairc> https://github.com/w3c/silver/issues/326

<alastairc> https://github.com/w3c/silver/issues/326#issuecomment-1017902188

alastairc: 7 agrees no comments
... any concerns?

<Chuck> proposed RESOLUTION: Accept Rachael's response to address issue 326

+1

<JF> +1

<bruce_bailey> +1

<Chuck> +1

RESOLUTION: Accept Rachael's response to address issue 326

<Detlev> +1

<mbgower> +1

WCAG 2.2 Focus appearance https://www.w3.org/2002/09/wbs/35422/wcag22-focus-appearance-enhanced2/

Chuck: Addressing because needs to be unblocked

Question 1 - Update to 'component' language

Chuck: moving onto WCAG 2.2
... Reads survey, 2 agree, 2 adjustments

Wilco: Text change to make the language more clear, reraise problem is solved with browsers and we're not taking into consideration

<alastairc> Wilco - could you check the previous minutes when you raise that other issue?

bruce_bailey: Didn't understand why Wilco said not UA focus option is not related, why not "until user agent" clause, might be worth discussing

Wilco: Not related because not about pull request

bruce_bailey: Would help address issue, about same SC

<Zakim> mbgower, you wanted to say is there any concern with using "area" as both a designation of context as well as a designation of size?

mbgower: Pre-existing, more nagging, use of "area" 3 times in SC, used in different ways, 1st is context, later is size
... not related to rewrite but jumping out more

Gregg: All are user agent, e.g., all text must be programmatically determinable, when UAs do that will be true, e.g., text of images, need alt-text today, won't in future

<Wilco> +1

Gregg: when UAs and ATs have it built in
... don't need to put on every provision, not requiring authors to do it

Wilco: Note in PR mentions size of component, should use "area" as elsewhere

AWK: PR response to past weeks, jumps out removing link to UI components, are there two definitions, WCAG and common usage?

<bruce_bailey> https://www.w3.org/TR/WCAG22/#no-keyboard-trap

alastairc: Yes, using in keyboard trap, UI component based on perception of unique function, visuals, leads to issues with drop shadows, how to size, things without border/background, removed link to definition
... focus on thing that's receiving focus

<bruce_bailey> If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface...

AWK: Keyboard trap, wouldn't recommend that language either, strong possibility of confusion, UI components, controls used for purpose
... can't justify separating

<Zakim> alastairc, you wanted to say the user-agent aspect we discussed last year, a lot, need a new issue (and new info) to revisit

<bruce_bailey> +1 to AWK, 2.1.2 is not clarifying

alastairc: Hit area better for evaluating size? Went through examples, no perfect way
... least issues if referring to component that has focus rather than perception of what component is
... tricky definition
... re Wilco's point, need new issue/info to tackle

<Zakim> bruce_bailey, you wanted to say 2.1.2 could use UIC no problem

bruce_bailey: Not comfortable with not using component as UI component

<Zakim> AWK, you wanted to ask for a walk through of the logic of how this addresses the checkbox+label issue

bruce_bailey: consider different word if we don't mean UI component

AWK: Issue around checkbox/label, so don't need enormous indicator

<Detlev> 2.1.2 - focus could theoretically get stuck on a non-interface component?

alastairc: Not problem for UI component or component, problem if mixing target with UI component

<alastairc> https://codepen.io/alastc/pen/eYGoKyP

alastairc: whether you're including visuals, did examples in codepen
... tricky with larger thing that look the same, different results depending on what you consider component
... share screen
... visual, component, target size, drop shadow can change, outline settings, odd examples, all produce different results
... how to differentiate
... to determine size need to determine edges

<bruce_bailey> i still am not seeing proble with using UIC

AWK: UI component definition may not fit in this case

alastairc: artificially expanded area, link is small (in card), is UI component card or link?

<Ryladog> Can we have s new term?

AWK: Not excited about changing meaning of component or removing definition, would rather say, 2 components, 1 is alternate version for other, don't like that either, talk about focused item

<Zakim> bruce_bailey, you wanted to ask if right hand kitten was a fail?

bruce_bailey: Clicking on heading in card, fail?

alastairc: Yes, if focus indicator is on heading, not clear what the interactive thing is

bruce_bailey: Include a note or use "element"

<Ryladog> Each interactive element recieves keyboard focus

alastairc: Component used elsewhere, leads to problems when trying to size

<mbgower> And this is without even considering 'proximity' :)

<Ryladog> Each individual interactive element receives keyboard focus

bruce_bailey: Card is decoration, not UIC

alastairc: Perceived, changes on over, looks active

<Ryladog> made interactive via tabindex

alastairc: could have sublink within that's also interactive

bruce_bailey: Not comfortable using component as something other than UI component

<Ryladog> yes

Chuck: Nobody's disagreeing with results, debating terminology
... is there terminology we can use?

<alastairc> When elements receive keyboard focus

<Zakim> mbgower, you wanted to say it's all about how you determine 'minimum area'

<Detlev> keyboard-focused entity?

mbgower: Comes down to defining minimum area, define by size of thing, friction between what visually looks like component and what's programmatically a component

Chuck: Outstanding question about what term works

<Ryladog> owww

<AWK> +1 Katie

<bruce_bailey> sorry, -1 on keyboard-focused entity

<AWK> Sounds like a User Interface COmponent

<Detlev> agree it doesn't work - just brainstorming... :)

<Ryladog> But maybe someone will have an epiphany during the week...

Chuck: Continue brainstorming, holding things up, but brainstorming more relaxed
... move on

Question 2 - Suggested update for understandability

Chuck: 6 agrees 1 adjust 1 something else

<bruce_bailey> https://www.w3.org/2002/09/wbs/35422/wcag22-focus-appearance-enhanced2/results#xq31

Chuck: Reads responses

bruce_bailey: List of items, 1 with subitems, last item isn't in list, having 1 requirement not in list isn't good

<bruce_bailey> i believe my survey suggestion to be editorial

<Zakim> alastairc, you wanted to answer Gundula's question

alastairc: Re Gundala's comment, do allow rounded rectangles, referring to perimeter, complex shapes, star, then will be easier to use bounding box
... but do allow for perimeter
... Wilco's comment, changes adjacent bullet to be stronger requirement

AWK: Also trying to understand that

<mbgower> I think it can be solved with a slight rewording of the second part of the sentence ",... the contrasting area must have a ratio of at least..."

Wilco: In current version, need contrast or thickness, for thickness need 2-pixel line meet 3:1 contrast, change, none need to meet 3:1 contrast for this bullet
... makes SC less strict

mbgower: Reads proposed change

<Detlev> this sounds incredibly dense...

AWK: Write them up, so it makes sense

<mbgower> I only changed a couple of words! :)

Chuck: Difficult to make sense of it

<ThompsonS> +1 to Detlev

<JF> +1 to Detlev

Detlev: What about people who just come to this?

alastairc: Partially because we keep changing, hopefully final wording will be clear

<Zakim> AWK, you wanted to ask Wilco to walk through his concern again

Wilco: Hard to talk through, come up with code example for next meeting

alastairc: Previously defined minimum area, that's used for contrast, adjacent contrast refers back to "minimum area" and use in contrast and adjacent contrast
... revised changed that
... change to "the contrasting area"

<Zakim> bruce_bailey, you wanted to ask about P on line 17 being a LI

bruce_bailey: Change p to li?

alastairc: was li, changed it

<Wilco> https://codepen.io/wilcofiers/pen/VwrwMVd

mbgower: Talking about the item with focus, not the focus indicator, now…
... will think about it

Wilco: Shares example, 1 px border, 1 px outline, before requires 2 pixels with 3:1 contrast

alastairc: Previously would have failed, if change to "contrasting area"? No
... yes

Wilco: Yes, that changes it

alastairc: Resolves Wilco's, return to it next week

<JF> bye all

This is scribe.perl Revision VERSION of 2020-12-31
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/page/user agent/
Succeeded: s/understand why it's not related/understand why Wilco said not UA focus option is not related/
Succeeded: s/you wanted to say 2.1.1 could use UIC/you wanted to say 2.1.2 could use UIC/
Default Present: alastairc, Lauriat, JakeAbma, JF, Jem, Wilco, Jen_G, Jennie, mbgower, jaunita_george, AWK, kirkwood, A_Ubbink, Detlev, shadi, Raf, sarahhorton, JustineP, Laura_Carlson, Rain, ThompsonS, Fazio, StefanS, Katie_Haritos-Shea, Rachael, david-macdonald, bruce_bailey, .75, Francis_Storr
Present: alastairc, Lauriat, JakeAbma, JF, Jem, Wilco, Jen_G, Jennie, mbgower, jaunita_george, kirkwood, A_Ubbink, Detlev, shadi, Raf, sarahhorton, JustineP, Laura_Carlson, Rain, ThompsonS, Fazio, StefanS, Katie_Haritos-Shea, Rachael, david-macdonald, bruce_bailey, Francis_Storr
Regrets: BruceB, ToddL, LeonieW
Found Scribe: Wilco
Inferring ScribeNick: Wilco
Found Scribe: sarahhorton_
Inferring ScribeNick: sarahhorton_
Found Scribe: sarahhorton
Found Scribe: sarahhorton_
Inferring ScribeNick: sarahhorton_
Scribes: Wilco, sarahhorton_, sarahhorton
ScribeNicks: Wilco, sarahhorton_

WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

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.)