<laura> Scribe: Laura
<AWK> +AWK
ac: announcement TPAC wed
unconference
... 14 sept 3 1 hour slots
<bruce_bailey> looking at: https://www.w3.org/WAI/GL/wiki/Meetings/TPAC_2022#Agenda
ac: not focused on our primary work but alternative things.
<Zakim> bruce_bailey, you wanted to ask to dial into Monday morning APA/COGA session
<Fazio> you're welcome
bruce: I am on travel for USAB, but I would like dial into Monday morning APA/COGA session..
<Makoto> Accessibility Support Subgroup - Presentation slides https://docs.google.com/presentation/d/1Oo7A6B44guvYaBkaFSBVaeSW1qCAglReaYqxSSsksNw/edit?usp=sharing
bruce: subgroup reports first one from makoto
Makoto: 5 participants
<Makoto> Accessibility supported Subgroup Wiki https://github.com/w3c/silver/wiki/Accessibility-supported-Subgroup
Makoto: Meeting minutes are
available on Subgroup Wiki.
... also our documents are linked from that page.
... Core Questions:
... How did the concept of "Accessibility Supported" work in
different countries/regions and/or organizations?
... Should we keep/modify the concept in WCAG 3?
... Document use cases
... Present pros and cons of Keep "Accessibility Supported" and
NOT keeping "Accessibility Supported" .
... let's revisit definitions.
<Makoto> [early DRAFT] “Accessibility Supported” in WCAG 2 https://docs.google.com/document/d/1XxzwsgWZSDh2EDqTag-nYfrqAT3b6Glpu8DGbVpTd9M/edit?usp=sharin
<Makoto> [early DRAFT] “Accessibility Supported” in WCAG 2 https://docs.google.com/document/d/1XxzwsgWZSDh2EDqTag-nYfrqAT3b6Glpu8DGbVpTd9M/edit?usp=sharing
Makoto: (reads from google
doc)
... gregg added historical notes to the doc. Much
appreciated..
... 6 Use cases in the google doc in no particular order
... Not sure if overlays should be included.
... efforts in Japan (jis)
... JIS is the National standard in Japan
... Several surveys of screen reader users in Japan
... PC-Talker is developed by a Japanese company
... PC-Talker tends to lag behind or be somewhat inferior to
NVDA and JAWS when it comes to HTML and WAI-ARIA support.
... PC-Talker had not provided headings navigation.
... accessibility supported has been essential in Japan.
... another example Use Case in W3C’s database
<jon_avila> This discussion also highlights how specific techniques may only benefit certain disability types and that accessibility supports needs to consider across disability
Makoto: it has an Unapproved
Prototyp label.
... We’d like to know the reason why this was
“unapproved”?
... Step 2. Pros and Cons
... for keep and not keep.
... Pros to keep: Allow WCAG to be adopted in different
countries / regions / languages.
... Allow owners (e.g. a webmaster for a website) to set the
specific target UAs/ATs for a product/service/website/app.
<alastairc> We'll switch to Issue Severity by 35 minutes past the hour, so there's a time limit on questions/comments.
Makoto: Cons to keep: Hard to
create/develop test files.
... Hard to secure human resources.
Time-consuming to test with different user agents including ATs.
Not Keep Pros : Make WCAG simpler
scribe: Make WCAG simpler,
judy: thank you.
<jon_avila> What I propose is that we allow people to use standard documented techniques/approaches without worrying about bugs - but if you want to use a non-standard approach then it has to be accessibility supported - that seems like a compromise to address both issues.
<Lauriat> Thank you Makoto and sub-group for putting this together! Very helpful to have the history clarified along with considerations from here.
judy: many reasons database didn't proceed.
<GreggVan> +1 to that
judy: major one was scalability.
<jeanne> +1 to Jon's idea. I would like discussion on that idea
judy: 4 less formal mechanism for crowd sourcing.
Shadi: data base was developed
with seed funding.
... scalability was a problem.
... also leared not everything is important or adopted.
... maybe focus on new features. couldn't be exhausted
... wasn't much buy-in from this group.
<Wilco> https://www.w3.org/community/aria-at/ and https://a11ysupport.io/
wilco: 2 groups one a community
aria-at group and a11y support group
... browsers are intentionally diverging from the standard.
<Lauriat> +1 to Wilco's questions/points for us to keep in mind as we move forward in this space
wilco: what do you go with the standard or the browsers.
gregg: we saw this as a
quagmire.
... real problem but solution is complicated.
<Zakim> alastairc, you wanted to suggest we create methods / test list, and AT vendors can fill in their support.
<GreggVan> +1
<bruce_bailey> link to 2.1 defined term: https://www.w3.org/TR/WCAG21/#dfn-accessibility-supported
<Lauriat> -1 to that idea as infeasible for the reasons Wilco raised
ac: could have vendors fill in for their products or crowd source.
AC: Issue Severity
<alastairc> https://docs.google.com/presentation/d/1-9AlgikV9idYF0JZBS8zvmaz9TxyYXt7M1zsNd_JbdI/edit#slide=id.p
<Makoto> Thank you so much for your comments and suggestions. We'll keep working on this topic with the inputs we got at this meeting today in our mind. Domo arigato so much everyone!
FS: members : Alastair, Francis,
Sarah, Shadi, Shawn, Todd.
... core questions:
... How can we ensure WCAG 3 better reflects the "lived
experience" of people with disabilities on the web?
<bruce_bailey> https://github.com/w3c/silver/wiki/Issue-Severity-Subgroup
FS: Approaches discussed
initially scoring & critical issues from the WCAG 3
FPWD
... Issue severity matrix
... Barrier score
(refer to google slides)
<sarahhorton> Severity worksheet: https://docs.google.com/spreadsheets/d/1MEdnI4CvrTlq1843MZfWLaIBGmoGXXQPpUOhEY1NgV4/edit?usp=sharing
https://docs.google.com/presentation/d/1-9AlgikV9idYF0JZBS8zvmaz9TxyYXt7M1zsNd_JbdI/
scribe: Test can be mapped to the
functional needs.
... Counting and assessing content feedback was all that not
positive.
<alastairc> Bruce - the Barrier Walkthrough method (at the end) has outlines for low-crit
<bruce_bailey> https://docs.google.com/presentation/d/1-9AlgikV9idYF0JZBS8zvmaz9TxyYXt7M1zsNd_JbdI/edit#slide=id.g149fac0acfd_0_19
<bruce_bailey> Note, that slide uses three tiers
scribe: Post-testing severity
evaluation
... post testing severity evaluation has positive and
considerations.
<Zakim> GreggVan, you wanted to add a 7th core question -- " how to do 1 through 6 in a way that is compatible with regulatory agencies so that WCAG 3 can be adopted by regulatory
scribe: Next steps Review any feedback from the group.
gregg: seventh question how do we accomplish 1-6 and be compatible with regulatory agencies?
<Zakim> bruce_bailey, you wanted to ask if have strawmen for tiers: low medium high critical
bruce: intrigued by what is the number of categories. We took a look at it and found it hard to be objective.
<Zakim> alastairc, you wanted to mention overlap with conformance / scoring
ac: 2 approaches.
... test level. functional.
... but is it going to line up?
<bruce_bailey> Mapping of WCAG 2.0 SC to Section 508 FPC: https://www.access-board.gov/ict/wcagtofpc.html
<bruce_bailey> Feedback on that is most welcome: 508@access-board.gov
ac: either make it a wide assessment or analyze each instance in the process of a task.
<Zakim> jeanne, you wanted to ask about critical errors proposal in user journeys? Is it so similar to Barrier Walkthrough that that same critiques apply?
jeanne: wanted to ask about
critical errors proposal in user journeys?
... thought it was a long term viable proposal.
... is it so similar to Barrier Walkthrough and that same
critiques apply?
... could be by functional needs or in context.
... would like to see context based.
ac: if we have critical issues. what are we doing with non-critical issues?
<jon_avila> I don't see how we could decide what is a critical issue or not without taking into different functional needs.
gregg: key question is critical
for who?
... that is what always stops me.
<bruce_bailey> This the webinar where Jeanne (and I) talked about WCAG3: https://www.accessibilityonline.org/cioc-508/archives/110939
<Lauriat> +1 to Gregg's point on equity, a massive challenge for this space
<jon_avila> That's why we need to tie critical to functional needs so we make sure we have considered all functional needs.
<alastairc> q/
<Zakim> Wilco, you wanted to talk about issue volume
gregg: coga ends up being labeled non critical.
<bruce_bailey> I agree that there was only positive feedback on the subject on critical errors.
<GreggVan> death by a thousand cuts
<jon_avila> I second Wilco that many minor issues combined can create a barrier
<Zakim> Lauriat, you wanted to note that the primary question seems to go beyond managing of issue severity itself (though certainly a large part of it)
wilco: if some one encounters issue after issue it is cumulative. (spoons)
shawn: the primary question seems to go beyond managing of issue severity itself.
ac: pricky to use issue severity
in conformance.
... would introduce too much complexity
<jon_avila> Prioritization of issues is important for people working toward fixing issues.
Chuck: We previously surveyed and
discussed the user-agents exception(s). As it was at the end of
the extended meeting some people had left.
... The positions and arguments seem to be well known, the
history of the previous answers is outlined there.
... We need to choose the path of least objections, so to
measure the strength of opinions, do you think: (options)
(reads results)
scribe: every option has some support.
<Wilco> scribe: Wilco
Chuck: ... reading GN's
comment
... Fairly uniform opinions, the plurality is on "don't mind",
the rest is evenly distributed.
... I'm not sure how to discuss it to get to consensus.
<laura> s/14 sept 3 1 hour slots /On 14 sept we have three 1-hour slots /
Alastair: Our default option is no change, because whatever happens we get objections.
Chuck: There is no "least resistant" path. We have an equal number of objections either way.
<Chuck> proposed RESOLUTION; Leae the user-agents exception(s) unchanged, and move the current state forward to CR
<laura> s/5 participants /we have 5 participants /
RESOLUTION: Leae the user-agents exception(s) unchanged, and move the current state forward to CR
Melanie: I'll take this offline
RESOLUTION: Leae the user-agents exception(s) unchanged, and move the current state forward to CR
Michael: An objection to the resolution has value, even if the chairs pass the resolution with objections.
-1
<Chuck> +1
<alastairc> +1
<MelanieP> -1
<jon_avila> +1
<bruce_bailey> +1
<jaunita_george> +1
<laura> +1
<Detlev> +1
<GreggVan> 0
<AWK> +1
<JakeAbma> +1
<Ryladog> +1
<ToddL> 0
Chuck: Resolution is passed, Melanie and Wilco have stated their objection
<laura> s/Prototype label./Prototype label./
<laura> s/also learned /also learned /
Chuck: 9 voted to accept the PR, 1 voted something else
GN: If there's a shadow, it's usually on one side, if the focus encloses it, it should be cemetric
AWK: The problem is we're trying to say what the focus needs to enclose. In 1.4.11 we do the same thing, having to determine the extent of the component for non-text contrast.
<laura> s/standard or the browsers./standard or the browsers?/
AWK: It seems strange to do it
one way in non-text contrast, and another way here.
... We can do as described, but there might be a better way by
aligning the SC.
Gregg: Both glow and shadow, you
can't tell where they end. They fade into something. Saying you
have to enclose them gives issues. At what point in the fade is
it faded out completely?
... Whether something has a shadow or not doesn't cause it to
stop looking like a button if you take the shadow away.
<jon_avila> I like Gregg's recommendation as a helpful option to consider
Gregg: As you get into 3d and other types of situations the shadow could move. It may be generated by the environment, not the author.
<Detlev> Agree with Gregg here
<Chuck> +1 with GV
Gregg: It could be fixed by saying if removed it does not change the identification of the object
<Zakim> alastairc, you wanted to answer Gundula's question and to say that it's about size more than enclosure.
<Ryladog> +1 to Gregg
Alastair: Wish that were the
case. To all three people's points, the main reason is not
about enclosing, and more about size.
... If you have a glow effect, the indicator is likely going to
be within the glow.
... It's hard to define the border of something. A piece of
text with no background may have shadow. How do you define the
size of something?
... non-text contrast doesn't have to worry about size at
all.
... We tried to define extraneous effects like shadow and glow,
but could not get agreement on that.
... We're thinking about this in today's technology. I'm
worried about having things like shadow be considered part of
its size.
<JenniferS> +1 to Gregg's point about forward thinking and being technology agnostic. XR is already a great example.
<SuzanneTaylor> +1
AWK: Yes, non-text contrast isn't about size, but we determine what the thing is. What on the page is the thing, and what is not the thing.
Alastair: The size of things can
vary, if you include those extra factors, generally you'll make
it bigger, you need a bigger focus indicator.
... If you increase the thickness slightly, a 2px outline, even
over the shadow is almost certainly going to pass.
<Zakim> GreggVan, you wanted to say a definition of extraneous might be "extraneous effect: anything that is added to an object/element that are outside of the object and if removed do
Alastair: I would be happy saying
not to include extraneous effects, but we had an objection that
that wasn't testable.
... If I had a button with a shadow, I would not expect the
focus to go around the shadow.
Chuck: Does Gregg's proposed definition help advance the concern?
Wilco: I don't think it's quite there yet but I imagine we can come up with something if we workshop it a bit.
Alastair: If we can get through the other questions we might be able to get back to it in the meeting, otherwise we'll work on it afterwards.
<laura> Global organizations can use WCAG adopting the same Method for the same Outcome everywhere.
<laura> s/Make WCAG simpler,/Make WCAG simpler,
<laura> Global organizations can use WCAG adopting the same Method for the same Outcome everywhere.
<laura> Global organizations can use WCAG adopting the same Method for the same Outcome everywhere.
<laura> s/Make WCAG simpler,/Make WCAG simpler,
<laura> Global organizations can use WCAG adopting the same Method for the same Outcome everywhere.
<laura> Global organizations can use WCAG adopting the same Method for the same Outcome everywhere.
<laura> s/@@/Make WCAG simpler, Global organizations can use WCAG adopting the same Method for the same Outcome everywhere./
Chuck: ... reading comments
AWK: My comment added suggestions from the last question. If we don't accept the changes.
<Zakim> alastairc, you wanted to deal with Wilco's comment.
Alastair: I think Andrew's original included the change into the second set of bullets. I didn't copy it across, but it does solve the problem Wilco raised
<alastairc> is at least as large as the area of a 1 <a>CSS pixel</a> thick <a>perimeter</a> of the unfocused component or sub-component, or is at least as large as a 4 CSS pixel thick line along the shortest side of the <a>minimum bounding box</a> of the unfocused component or sub-component, and
<Chuck> Wilco: This does address my concern. I don't think this changes anything. If you have a component with sub-components, if you focus the components as a whole, the focus indicator wraps around all the sub components.
<Chuck> Wilco: If you leave that around the big one, you leave it around the smaller sub-components.
AWK: If I can restate, for
example if you have a set of tabs, and the focus outline is
around all tabs, if the focus moves
... if the focus is still around all those tabs.
<jon_avila> How does the user know then that the 3rd tab is selected rather than the first if they are all focused with a single indicator?
AWK: For the combobox, it can
stay around the combobox option. That might be true, but I
think it would fail 2.4.7.
... If you don't show the programmatic focus where it actually
is, then I think you're failing. It may not be as
dramatic
... part of the intent with focus visible, the programmatic
focus is visible. I think that would still be a problem.
Yes, I agree, it just wouldn't have the minimum area
Katie: A larger focus on a calendar, with buttons, I guess the visual focus should move where you move inside the component. I'm not understanding exactly.
<Zakim> alastairc, you wanted to ask if we can just remove the concept of sub-components?
Alastair: For some components,
you have the selection state. You might be focused on the
parent, like a select box, and with arrow you move the
selection.
... That is a state change.
... My question is if we can drop sub-components. Maybe add a
note instead.
Chuck: We had the benefit of the statement, not objectionable to Wilco.
<alastairc> PR updated: https://github.com/w3c/wcag/pull/2625/files
<alastairc> I'm not objecting, I'll leave it
<Chuck> Wilco: Yes this amendment solves my comment. but the sc doesn't change with this addition. As for removing sub-component, I don't think we should do that. This addresses some challenging issues.
AWK: Agree with that too. Part of the challenge, some components where the parent is never focused. A set of tabs is an example of that. It's always a tab that's focused, rather than the parent
<Chuck> proposed RESOLUTION: Accept amended PR 2625.
AWK: Other times it switches between the parent and the sub-component. I think we need both, unless we restructure it to be about things that have focus, which introduces other issues.
<jaunita_george> +1
<Chuck> +1
<AWK> +1
<Ryladog> +1
<laura> +1
<alastairc> +1
<bruce_bailey> +1
<maryjom> +1
+1
Alastair: Some of the bottom notes may be out of sync with other PRs. This removes the bottom paragraph.
RESOLUTION: Accept amended PR 2625.
Chuck: 12 accepted the PR, 4 with changes, 2 something else
Melanie: I think my comment was from last week
<Zakim> alastairc, you wanted to clarify changes
Alastair: On GN's point, there
are two main changes. I think "entire" would be good, as there
is no size measurement. There is no accounting of gradients.
It's simpler but relatively difficult to meet.
... Putting "entire" in helps differentiate it from the second
bullet.
... The "adjacent non-focus-indicator colors" does make it
wordy. My proposal would be to take on "entire" and leave the
"non-focus indicator" addition.
GN: Focus indicator with a glow effect would fullfill the second bullet, but not the first, correct?
Alastair: Correct.
AWK: To be clear, if it has a glow-effect that encloses a button, and it is entirely outside the button, that would still be the first bullet?
Alastair: It could be. That
depends on if we disregarded glow effects.
... If you had an indicator that went around the component.
Typically you see outlines that go over the shadow / glow
AWK: I was thinking more you have a crisp button, but the focus has a glow effect.
Alastair: That would be fine.
AWK: If it has a two-pixel focus indicator, where one of the pixels overlaps with the button. If we say the entire focus indicator encloses it, that makes more sense to me.
<Chuck> Wilco: If you have a focus indicator that has a glow effect, you have guaranteed to have some part of the indicator be less than 3:1. You would need to perform test on entire area.
AWK: That makes sense
<Chuck> AWK: we are saying that the same pixel in focused and unfocused states don't necessarily have a contrast ration of 3:1. Glow will be more subtle.
<alastairc> The simple view of the change: https://w3c.github.io/wcag/guidelines/22/#focus-appearance
<Chuck> proposed RESOLUTION: Accept amended PR 2568 to address MG's request for clarity.
<Chuck> POLL: Do we want to include "non-focused-indicator" colors in the PR
<alastairc> Should the change include "as a contrast ratio of at least 3:1 against adjacent [INS]non-focus-indicator[/INS] colors."
<Chuck> POLL: Should the change include "as a contrast ratio of at least 3:1 against adjacent [INS]non-focus-indicator[/INS] colors."
-0.5
<alastairc> -0.5, could live with it, but think it only makes it wordier.
<Rachael> -.5
<GN015> +1
<Chuck> +.5
<AWK> 0
<OliverK> +1
<jaunita_george> .5
<Detlev> 0
<ToddL> 0
<laura> 0
<jaunita_george> +.5
<bruce_bailey> 0
<JakeAbma> 0
<Ryladog> 0
Chuck: Not strong against, any objection to including this?
<maryjom> .5
<AWK> This seems like an editorial tweak that could be changed if we get comments in CR.
<JenniferS> +1
<Chuck> proposed RESOLUTION: Accept amended PR 2568 to address MG's request for clarity.
<jaunita_george> +1
Mary Jo: I was wondering if we should check with people who aren't working on the SC. Check with developers / designers who are trying to understand this SC if the change is helpful.
Chuck: We don't regularly, on a case by case we do go to specific groups. In general we've felt that polling here and votes on github help.
Alastair: There are a couple of
levels to that. I think it's necessary for people who have been
close to it to monitor it.
... The second aspect is if people who are involved understand
what it mean. Not just do they think, but does the
understanding match what we intended.
... It is possible to interpret things in very different ways.
That's where the understanding documents come in.
<Chuck> proposed RESOLUTION: Accept PR 2568
0
<jaunita_george> +1
<Chuck> +1
<alastairc> +1
<JenniferS> +1
<laura> +1
<bruce_bailey> +1
<maryjom> +1
<Rachael> 0
<JakeAbma> +1
<Detlev> 0
<AWK> +1
RESOLUTION: Accept PR 2568
<GN015> I lost track what is part of the resolution and what is the amendment.
Alastair: One of the proposals is
to adjust from WCAG 2.2 onward
... There are two interpretations, 10 opportunities, or 10
times the default time. There are 7 no's to 2 yes.
... The other proposal was to stop the misinterpretation for
WCAG 2.1 and 2.0, to include an errata to say there are 10
opportunities. That's the version they're most likely to
pass.
... It seems like the safer option.
Gregg: If we're not going to get consensus it just stays what it is, and get interpreted loosely.
Alastair: We're left with different people interpreting things in different ways.
<alastairc> No resolution, but discussing tackling in the understanding doc
<JenniferS> If there are folks misinterpreting things, if we can do something to clarify, shouldn't we?
<alastairc> Note: The provision to extend is intended be equal to the 10 times original time limit. However since this was not clear from the language for this provision ian extension of any length is accepted for conformance to WCAG 2.0 and 2.1.
<alastairc> RRSAgent make minutes
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/access have an event. but will dial in for Monday meeting/I am on travel for USAB, but I would like dial into Monday morning APA/COGA session./ Succeeded: s/PC-Talker does not work with headings./PC-Talker had not provided headings navigation./ Succeeded: s/announcemnt /announcement / FAILED: s/14 sept 3 1 hour slots /On 14 sept we have three 1-hour slots / FAILED: s/5 participants /we have 5 participants / Succeeded: s/it is the Natio0nal standard in Japan/JIS is the National standard in Japan/ FAILED: s/Prototyp label./Prototype label./ Succeeded: s/mechnisins/mechanism/ Succeeded: s/deveoped /was developed / FAILED: s/also leared /also learned / Succeeded: s/communtiy group /community aria-at group / Succeeded: s/a11y support/a11y support group/ Succeeded: s/intentionallly / intentionally/ FAILED: s/standard or the browsers./standard or the browsers?/ Succeeded: s/for thier products or croud /for their products or crowd / Succeeded: s/sevnt question how do we accompich /seventh question how do we accomplish / Succeeded: s/intreged /intrigued / Succeeded: s/apporaches/approaches/ Succeeded: s/fucntional/functional/ Succeeded: s/accessment /assessment / Succeeded: s/anayies/analyze / Succeeded: s/that that /and that / Succeeded: s/goes beyond issues severity./the primary question seems to go beyond managing of issue severity itself./ Succeeded: s/@@/Make WCAG simpler,/ FAILED: s/@@/Make WCAG simpler,/ Succeeded: s/@@/Make WCAG simpler,/ FAILED: s/@@/Make WCAG simpler,/ Succeeded: s/@@/Make WCAG simpler,/ FAILED: s/@@/Make WCAG simpler, Global organizations can use WCAG adopting the same Method for the same Outcome everywhere./ Succeeded: s/Prototyp /Prototype / Succeeded: s/leared /learned / Succeeded: s/intentionallydiverging/intentionally diverging/ Succeeded: s/stndard /standard / Default Present: alastairc, JakeAbma, Laura_Carlson, Lauriat, AWK, bruce_bailey, Fazio, maryjom, Makoto, ToddL, Chuck, sarahhorton, SuzanneTaylor, Detlev, JenniferS, MelanieP, jon_avila, GreggVan, jeanne, Jen_G, kirkwood, jaunita_george, StefanS, Judy, Katie_Haritos-Shea, Francis_Storr, Rachael, .5, GN Present: alastairc, JakeAbma, Laura_Carlson, Lauriat, bruce_bailey, Fazio, maryjom, Makoto, ToddL, Chuck, sarahhorton, SuzanneTaylor, Detlev, JenniferS, MelanieP, jon_avila, GreggVan, jeanne, Jen_G, kirkwood, jaunita_george, StefanS, Judy, Caryn, Katie_Haritos-Shea, Francis_Storr, Rachael, GN015 Found Scribe: Laura Inferring ScribeNick: laura Found Scribe: Wilco Inferring ScribeNick: Wilco Scribes: Laura, Wilco ScribeNicks: laura, Wilco 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.)[End of scribe.perl diagnostic output]