Previously Gundula had raised that focus indicators using border on wrapping text links should pass.

The problem arises when you use CSS border (not outline), and a wrapped text-link leaves a gap on each side of the separated link.

Michael Gower is proposing a different solution to the same problem, where we add to the perimeter definition to outline why wrapped links are ok:

"For text links, the perimeter can be established based on how the link would appear contiguously across a single line. Links that break across multiple lines are not considered to have a larger perimeter."

This is implemented in PR 2420. (The definition is the area of focus, there are other understanding updates that can be discussed separately.)

We discussed this again briefly in May, but ran out of time.

Do you:

Summary

Details

Based on previous comments a slightly updated structure has been suggested, where the exceptions about size/contrast are brought up as an alternative to the primary bullets.

This structure update can be previewed.

This is a last minute adjustment, if we don't agree that it is better, we go with the current structure.

Do you:

Summary

Details

We have had a few updates recently, this is a chance to review the whole SC text in this preview.

Do you:

Summary

Details

Michael Gower updated Focus Appearance (Enhanced) language to combine original Enhanced requirements with updates to Minimum language requirements. As part of this, he proposed creating Minimum and Enhanced versions of Focus Not Obscured. There is no increase in requirement outcome, they are just broken out into separate SCs that match the previous versions.

Previews of:

• Focus appearance (enhanced)
• Focus not obscured (minimum)
• Focus not obscured (enhanced)

Do you:

Summary

Details

Previously Gundula had raised that focus indicators using border on wrapping text links should pass.

The problem arises when you use CSS border (not outline), and a wrapped text-link leaves a gap on each side of the separated link.

Michael Gower is proposing a different solution to the same problem, where we add to the perimeter definition to outline why wrapped links are ok:

"For text links, the perimeter can be established based on how the link would appear contiguously across a single line. Links that break across multiple lines are not considered to have a larger perimeter."

This is implemented in PR 2420.

Do you:

Summary

Details

One of the (agreed) changes was to use "adjacent colors" in the last bullet point:

Has a contrast ratio of at least 3:1 against adjacent colors, or is no thinner than 2 CSS pixels.

The previous version of this was:

Where the area is adjacent to the component, it has a contrast ratio of at least 3:1 against the component or a thickness of at least 2 CSS pixels.

In practice the difference is slight, but would mean:

• A focus indicator that uses a gradient would need to have a 2px minimum thickness because it would (probably) not contrast with the rest of the indicator.
• A focus indicator that is not adjacent to the UIC is still required to have adjacent contrast with the surroundings. For example, if the indicator appeared adjacent to another control or a different background would be required to have contrast (or thickness).

Wilco raised this in issue 2333.

Do you:

Summary

Details

There was a question of the last section of the SC text which is currently:

Where a user interface component has active sub-components (for example, an opened drop-down menu shows a list of menu items), if the focus indicator is applied to the sub-component then these requirements can be applied to the sub-components.

The question was: Does that mean the requirements apply to both the component and the sub-components?

The intent was not to apply to both, so the word "instead" has been added.

Where a user interface component has active sub-components (for example, an opened drop-down menu shows a list of menu items), if the focus indicator is applied to the sub-component then these requirements can be applied to the sub-components instead.

Note that there is some flexibility, the requirements "can" be applied to the sub-components, but the author could decide that it is better to apply to the parent component instead or as well.

There is a section of the understanding document which covers this scenario.

Do you:

Summary

Details

Gundula posted in a recent survey question and it was transferred to issue 2323.

There are two suggestions, one is to expand the definition of minimum bounding box to:

the smallest enclosing rectangle aligned to the horizontal axis within which all the points of a shape lie. Where a component consists of disconnected parts, such as a link that wraps onto multiple lines, each part is considered to have its own bounding box. Insert: In such a case, the base for further measurement is the concatenation of all boxes for disconnect parts. In the example of a link that wraps onto multiple lines the resulting box would enclose the same link if it would not wrap.

The second suggest was to update the normative from "a" to "the" minimum bounding box:

Is at least as large as the area of a 1 CSS pixel thick perimeter of the unfocused component, or an area at least as large as a 4 CSS pixel thick line along the shortest side of the minimum bounding box of the unfocused component;

Should we:

Summary

Details

The question regarding "Replace 'encompasses' with 'encloses'" was accepted, and in the last meeting we agreed to use "Encloses", it's definition, an update to "minimum bounding box", the note on declared values, and "adjacent colors" in the SC text. The updates can be previewed.

These updates (when the understanding doc is updated) should allow us to close issues:

• Issue 2219
• Issue 2222
• Issue 2226
• Issue 2237

The understanding document adds some explanation around these factor. Preview of the changed document.

Remembering that further changes can be made later, do you:

Summary

Details

Pavel asked, in Issue 2204 about a scenario where a menu can be hidden (sometimes) as you are tabbing through it.

The response says that it already covered by 2.4.7.

Do you:

Summary

Details

The question regarding "Replace 'encompasses' with 'encloses'" was accepted, as such this is an update to the understanding document to add some explanation. Preview of the changed document (mostly near the top).

Do you:

Summary

Details

In recent meetings we have agreed to progress with a re-worked version of focus appearance (preview).

One part of that still under discussion was the use of "Encompasses" in the first part, which some people were not sure meant solid.

A recent suggestion from MichaelG was to use "Enclosed" instead, so the SC would start:

When a user interface components has keyboard focus, the focus indicator:

• Encloses the visual presentation of the user interface component;

The definition would be: "Solidly bounds or surrounds".

Do you:

Summary

Details

We have previously discussed using terms other than "User Interface Component", with inconclusive results.

We have also discussed using various basis's for size including the target size, the underlying code, and the perceived size.

The proposal in the document is:

• We use "User interface component", which is based on the perceived control.
• One input to that perception is what has a focus indicator (passing 2.4.7). E.g. if you tab to a component and it shows a focus indicator, that is useful for working out the size of the component.
• It can be the element (e.g. a link), but it could be larger or smaller than that based on what you see. For example, a button with no background/border could have any size indicator that is bigger than the content (text) of that button.
• The component with perecived focus may be an active descendant of a component. I.e. focus for the UIC is NOT based on browser’s programmatic focus. See the aria examples towards the end of the table in the document.

You can see useful examples for this interpretation that include the text “#UIC-SIzing” in the document.

Do you:

Summary

Details

As part of the updates shown in the Focus appearance reboot document, we added a note:

NOTE: Where a user interface component has active sub-components (for example, an opened drop-down menu shows a list of menu items), this Success Criterion applies to the item with keyboard focus

The purpose is to make clear that when evaluating the SC you would use the item with focus rather than the parent.

The other notes (that you can see in the editor's draft at the moment) have been removed as they do not seem to be needed with this version.

Do you:

Summary

Details

There is one change in scope compared to the previous version: When using the primary part of the new SC text, it does not allow for indicators with gradients, or thick indicators that lack adjacent contrast. However, the exception will cover almost every circumstance of that.

Mathematically, a 1px outline around a component will always be bigger than a 4px bounding box multiplied by the shortest side, except for:

• A circle (or very circular oval) will have a 1px perimeter that is slightly smaller than the minimum. That would pass the primary part of the SC if it has contrast, but it would not if it included a gradient/halo. There is an example in the table in the document.
• A square component with drop-shadow (or other decorative effect). E.g. a 100x100px square would have a 396px perimeter, or a 400px area for the exception metric (that is where the "1px perimeter" and "4px shortest side" metrics meet). With a drop-shadow the visual expands it but neither metric is met by a simple outline that doesn’t include the shadow.

Any rectangular element with an outline will pass even if it has a decorative effect expanding the visible size of the element.

An option for this aspect is to exclude ‘decorative effects’, e.g. “encompasses the user interface component, excluding decorative effects”, however that is difficult to define.

Another option is to add the 1px perimeter metric as another way of meeting the guideline in the exceptions. E.g:

An area of the focus indicator:

• is at least as large as the area of a 1 CSS pixel thick perimeter of the unfocused component, OR
• is at least as large as a 4 CSS pixel thick line along the shortest side of a minimum bounding box of the unfocused component, AND
• (Other bullets)

This adds to the complexity of the exceptions.

Should we:

Summary

Choice	All responders
	Results
Accept that some rare 1px perimeter cases may fail (requiring a 2px indicator), keep the proposed SC	5
Accept some additional complexity and add the 1px perimeter metric to the exception	2
Something else	3

Details

Responder	Not including the 1px perimiter metric	Comments
Andrew Somers
Ben Tillyer
Jake Abma
Marc Johlic
Rain Breaw Michaels
Glenda Sims
Gregg Vanderheiden
JaEun Jemma Ku
Kim Dirks
Abi James
Patrick Lauke
Sarah Horton
Michail Yasonik	Accept some additional complexity and add the 1px perimeter metric to the exception
Detlev Fischer
Oliver Keim	Something else	in the document the sentence "White outline on a dark grey shadow, where the shadow visually increases the size of the button." indicaters a larger button, but the button has the same size. The shadow may help to perceive the button as a larger element, but the physical size remains equal, for unshadowed or shadowed state.
Caryn Pagel
Laurence Lewis
Stefan Schnabel
Peter Bossley
Jaunita George
Gundula Niemann	Something else	In the past, we had the wording "an area of the focus indicator meets the following". We can use it again. It is not complex, it just says, if a part of the focus indicator fulfills, it fulfills as a whole. So it could say: "When a user interface component has keyboard focus, an area of the focus indicator meets the following:" The exception already talks about an area of the focus indicator in the relevant place. The second bullet point in this question rather describes an issue arising when including the shadow of the focused component into the size measurement. A shadow does not increase the visual size of the element, it adds emphasis, but not size. Accordingly, the size of the focused User Interface Component should be measured without shadow or halo. I did not see an example where the focus indicator itself has a shadow or halo and is not a browser default. So I did not find the example referred to in the first bullet of this question.
David MacDonald
Andrew Kirkpatrick
Ian Kersey	Accept some additional complexity and add the 1px perimeter metric to the exception
Todd Libby
Suzanne Taylor
Melanie Philipp
Wilco Fiers	Something else	This isn't just a problem for ovals. This is true for anything with rounded or clipped corners. I wouldn't consider those rare. I'm not all too sure what a "decorative effect" is. In WCAG lingo isn't everything that doesn't require semantics under 1.3.1 a decorative effect? I'm all in favor of simplification on this SC, but while well intentioned, I feel this new proposal has had the opposite effect. It's a good attempt, but it has added complexity and it has failed to account for edge cases that the current version did.
Laura Carlson	Accept that some rare 1px perimeter cases may fail (requiring a 2px indicator), keep the proposed SC
Charles Adams
Michael Gower	Accept that some rare 1px perimeter cases may fail (requiring a 2px indicator), keep the proposed SC	I think simplicity of text overrules these few edge cases. They do not suffer from a 2px indicator.
Bruce Bailey	Accept that some rare 1px perimeter cases may fail (requiring a 2px indicator), keep the proposed SC	I am also okay with second choice to accept some additional complexity and add the 1px perimeter metric to the exception.
Jonathan Avila
Mary Jo Mueller
Rachael Bradley Montgomery	Accept that some rare 1px perimeter cases may fail (requiring a 2px indicator), keep the proposed SC
Alastair Campbell	Accept that some rare 1px perimeter cases may fail (requiring a 2px indicator), keep the proposed SC	Oliver wrote: "The shadow may help to perceive the button as a larger element, but the physical size remains equal, for unshadowed or shadowed state." Gundula wrote: "A shadow does not increase the visual size of the element, it adds emphasis, but not size. " AC: Unless we have a good definition of "decorative" that includes shadows, which we then exclude from the size metric, a shadow will increase the perceived size of the component. If you ask someone to draw a box around a component, I think they would include the shadow. Therefore the outline in the shadow example is *inside* the component, and doesn't pass the primary part of the proposed SC text. These comments really apply to the next question. Gundula also wrote: "In the past, we had the wording "an area of the focus indicator meets the following". We can use it again. It is not complex, it just says, if a part of the focus indicator fulfills, it fulfills as a whole." AC: We had quite a few comments saying that it is complex, that is why we tried to lead with a simpler version to start with, and put the complexity into the exception. Wilco wrote: "This is true for anything with rounded or clipped corners.". AC: Not really, they have to be square or close to that. E.g. a very short link with text in it, like <a>Link</a> in the browser defaults is 29 x 19px. Therefore the 4 * shortest size metrix = 76px. The outline is 96px. You can't loose 20px in corners without overlapping the text! It has to be close to square/round It will apply to things like checkbox & radio buttons, but I think that's a good case where a thicker indicator is warranted.

The new version in the document uses a new definition termed "encompasses".

Continuously surrounds, bounds or includes the whole of

The "continuously" was added to address concerns that you could just put little lines on each corner with big gaps in it.

The definition is used in "When a user interface component has keyboard focus, the focus indicator... encompasses the user interface component"

There was a suggestion to add to the definition "... except for effects that appear to be outside the boundary of the control". However, that would require you to evaluate:

• what constitutes a decorative effect;
• what the boundary is without the decorative effect;

That brings in some new problems. The alternative is that the exception is used. For example, if a button has a drop-shadow and uses a standard outline, the outline will be over the shadow, inside the boundary of the component. The "drop shadow" example in the document shows a passing version of this method. See also the section on "scope change".

Do you:

Summary

Details

In recent weeks we have reviewed an overhaul of the SC text from Michael Gower,
please see this overview of the update with test cases.

Recently resolved items include:

• Separating the 'unobscured' aspect helped to make the SC simpler, and moved out the timing aspect to that SC. The group considered that a fading indicator was not sufficient (for the baseline for authored content).
• Using "user interface component" as the object of scope.

Although this is one update, and one big survey question, in the meeting we will cover these topics as individual items (plus any others raised in the survey comments):

• The proposal assumes that the vast majority of 'decorative effects' such as drop-shadow would pass via the exception. The alternative is to ignore decorative effects (see the "Scope change" section).
• Using the UIC perceived size for the metric (Issue #2226).
• Solving the problem of 1px outlines not being sufficient due to taking a border box (Issue 2222)
• Application to 'active descendent' items (Issue 2237), which is covered in the document linked above.

The overall question is whether to accept the proposal, but please do make comments on any of the sub-points.

Summary

Details

On December 21st we had a discussion about focus visible and user agents, and resolved to "Carry on with the SC as it is and provide guidance in understandings that browsers can fulfil the SC if you test it, with 1 objection requesting including a default focus indicator."

This issue has been raised again in issue 2201.

Uncontested points included:

• Chrome and Edge (about 75% of desktop browser share) now include an option to add a forced focus indicator.
• There is no similar mechanism for mobile usage (over 50% of global browser share).
• The default indicators for Firefox and Safari are still problematic.
• The SC as written does allow for default indicators to pass, which maybe useful in closed environments where the browsers are known.

There were also points made about the difficulty of implementing the SC, although this was contested both on the actual difficulty, and that we have got to this point by trying to balance the user need with the flexibility and complexity.

Another contested point is how effective the forced focus indicators are because they fade after a couple of seconds. (See the issue thread for more.)

Please consider how/whether an SC should account for browser variations. For example, does an advanced/accessibility setting in a browser fulfilling the user need? Would author effort on this SC take away from other requirements?

Another aspect is whether this should be something that authors have to tackle when it could be accomplished by user agents. For context, we have SCs which:

• Can only be fulfilled by authors, such as Headings and Labels.
• Are better when fulfilled by authors but the requirement can be somewhat met by user-agents, such as alt-text.
• Are intended to make sure that sites function well when user-agents do over-ride the authored styles, such as text-spacing / sizing.
• Can be met by the user-agent or the author takes on the requirement if they update it, such as non-text contrast.
• Can be fully met by user-agents, but that may not be popular/known enough, such as 1.4.2 (muting a tab)

The original intent (coming from developing 1.4.11) was to ensure that poor browser defaults are not enough (article summary from Adrian Roselli). The SC does allow for browser defaults to meet the SC if they meet the requirements, but it does not allow for meeting the SC using extra settings / AT.

The suggestion from the thread is to add an exception: "except where the appearance of the focus indicator is determined by the user agent and not modified by the author".

Do you think we should:

Summary

Details

Based on the (un-discussed) survey responses last week, Alastair put together one PR to wrap all of the changes into one new version in PR 2230, which you can preview.

NB: It doesn’t show the links to definitions there, but none are new definitions. Also, the understanding document will need an overhaul if the SC proposal is agreed.

To summarise the updates:

• Added an exception for when the user-agent does not permit styling of the component.
• Incorporated most of Andrew's understandability update, except the 'adjacent' bullet.
• Adjusting the size metric to use the definition of User Interface Components, but set the minimum size as a bounding box around the content of the control, i.e. the text or icon. See Issue 2226 for more on that specific update.
• Move the timing aspect to only apply to the ‘obscured’ clause, which is where it was intended to target originally.

From the discussion on list, it appears that discussion of the sizing method is where we should focus. For example, moving from using the perimeter to using a bounding box around the content.

Do you:

Summary

Details

In a previous discussion AndrewK suggested an update to the SC, aiming to keep the requirement the same but make the text easier to understand..

The suggestion was implemented in PR 2182. This was previously surveyed with just a couple of comments to update

The update was to address the concern that it opened up a loophole for the adjacent contrast, which was addressed by changing "focus indicator" to "contrasting area" in the adjacent contrast bullet (in this update).

It also updates the intro to say "meets all the following" (addressing Bruce's comment about consistency).

Do you:

Summary

Details

There is a problem with using "user interface component" as the scope of focus-appearance, which is that the definition scopes it the appearance of a component, and it doesn’t (seem to) cover descendant elements which get keyboard focus such as grid items or options in a select. To summarise the issues:

• Scoping to the appearance leads to odd results for components which have effects like drop-shadow, and items like "cards" where CSS/JS can be used to disguise what the component is. Different people would get very different results for the question: how big is this component.
• User-interface components include, as one thing, active descendents like grid cells or drop-down options. That would leave the thing the user thinks has focus out of scope.
• We don’t want to require focus indicators on non-interactive things like landmarks.
• We don't want to cause confusion by adding a similar term to user-interface controls.

Alastair tried wording that would remove the concept of component so that it was anything with focus, but that became a self-referential mess.

The starting sentence of the SC which sets this scope is:
"When [things] receive keyboard focus, the focus indicator meets the following:

Suggestions for “things” are:

• "Components"

  (Four SCs use just “component” without “user interface”: 1.3.3, 2.1.2 Keyboard Trap, 2.4.3, 3.2.4.)

• Elements

  (Used by 4.11 in a similar way to our intent here, and “visual element” is used by 1.4.1 in a different way.)

• Controls

  (Two SCs use “control” as a noun without “user interface”: 1.1.1, 2.5.5.)

These would be combined with a term to ensure it is only interactive things that are in scope, e.g. keyboard operable components. The PR that would be updated by this decision is PR2188.

Which would be your favourite (yes and prefer), ok (yes), just about ok (yes but prefer not) and couldn't tolerate (no).

Summary

Ranking of choices in order of least unacceptable/most prefered:

Ranks	All responders:
1	Controls
2	Components
3	Something else
4	Elements

Details

JonA raised Issue 2219 about the first part of the SC text, "When user interface components receive keyboard focus".

This text was used to ensure that the item receiving focus is itself visible, so that its focus indicator provides some benefit. It also acknowledges that there are circumstances where the viewport or content may end up hiding the focused element after it gains focus.

At the time we had not considered indicators which fade out after a short time.

Also remember that 2.4.7 focus visible has text in the understanding document that says "The focus indicator must not be time limited, when the keyboard focus is shown it must remain.". However, focus-visible doesn't define what visible means.

MichaelG suggest updating the start and end of the SC to make that aspect only applicable to the "obscured" part. This has been implemented in PR 2223.

Do you think we should:

Summary

Details

After the previous discussion on focus-appearance and how to measure the size of a component, a couple of small changes were discussed to make that clearer. These have been implemented in PR 2188.

The aim of the change is to:

• Make it clear that it is the underlying size of the component that is the basis for measurement, and in HTML that aligns to the location of the CSS border.
• Remove 'user interface component', because that definition is based on perception of the component.

Do you:

Summary

Details

In a previous discussion AndrewK suggested an update to the SC, aiming to keep the requirement the same but make the text easier to understand.

The suggestion was implemented in PR 2182.

Do you:

Summary

Details

Based on a previous conversation a discussion document has been created to outline the arguments for the current approach, and for using target-size as the basis for the size measure in focus-appearance.

The questions to consider are:

• Is using the concept of component sufficient for calculating the size of a component?
• Are the niche problem cases for either approach a blocker?
• Would using the target size be a better approach

Should we:

Summary

Details

Wilco would like to use the target-size of the component as the basis for size metrics.

PR 2147 makes the change in the SC text. If we agree this, the understanding document will need updating.

Please consider:

• How you thought the size of a component would be measured before.
• Components which use javascript to increase the hit area.
• Components which have 'extra' stuff around their boundary, e.g. drop-shadow.

An alternative would be to leave the SC text alone, and update the note from:

"If the component has a visible boundary smaller than the hit area, or the size of the component is not available, the minimum area can be taken from the visible boundary." to

"The component size is measured up to and including the border. If the size cannot be programatically determined you can use the visible boundary. If there is no visible boundary you can use the bounding box."

Should we:

Summary

Details

priyankad7 raises issue 1842 to say it is too complex.

Alastair created a proposed response.

UPDATE: We have separately discussed the user-agent aspect and resolved not to include an exception for that.

For the comments agreeing that it is too complex, we iterated this a lot and we have found another "triangle", adjusting one of these factors positively will then negatively impact the others:

• How easy the SC is to understand;
• How large a range of design options are available;
• How accurately it maps to the user-benefit.

There is a simpler version, it is at AAA level because it reduces the design options. We could allow for known poor-indicators to pass. These are the options for making the SC simpler.

Do you:

Summary

Details

Following the discussion on focus-appearance complexity, a question was raised about whether the user-agents are fulfilling the user-need.

Uncontested points included:

• Chrome and Edge (about 75% of desktop browser share) now include an option to add a forced focus indicator.
• The default indicators for Firefox and Safari are still problematic.

There were also points made about the difficulty of implementing the SC, although this was contested both on the actual difficulty, and that we have got to this point by trying to balance the user need with the flexibility and complexity.

Please consider how/whether an SC should account for browser variations. For example, is a (fairly hidden) setting in a browser fulfilling the user need? Would author effort on this SC take away from other requirements?

One possible way forward is to add 'mechanism is available' language to explicitly allow for browser-based solutions. For example, "A mechanism is available so that when user interface components receive keyboard focus, an area of the focus indicator meets the following:"

Do you think we should:

Summary

Details

Ben opened Issue 1858 about whether the examples are sufficient.

Alastair & David proposed a response, essentially - we agree but not allowing for those examples would create false-positives.

Do you:

Summary

Details

John Foliot requested visual examples be added to the normative guidelines document for focus-appearance in Issue 2071.

Alastair proposed a response (essentially "no, we have lots in the understanding doc").

Do you:

Summary

Details

In bladerunner issue 2049 Bruce raised that: WCAG 2.1 added the word "state" to the glossary for non-text contrast, which is a term that was already used by 4.1.2 Name/role/value.

Focus appearance (min + enh) uses the term "state" in the contrast bullet:

Contrast: The area has a contrast ratio of at least 3:1 between its colors in the focused and unfocused states.

Bruce is concerned that the usage in focus-appearance implies that 4.1.2. includes requirements for authors to programmatically expose all user interaction possibilities.

Alastair thinks that focus is a state, both visually and programmatically, but not one that authors need to worry about under 4.1.2.

There is plenty to read in issue 2049 if you'd like more details.

If we were to change focus-appearance it would be to something like:

Contrast: The area has a contrast ratio of at least 3:1 between the colors when the component is focused and when not focused.

Should we:

Summary

Details

We have previously discussed Issue 2017 regarding focus indicators for larged editing areas such as Documents and code editors. We generally agreed that this type of thing was not a distinct user-interface-control, therefore wasn't in scope.

Alastair and Michael created PR 2081 to add a paragraph to the understanding document to explain this.

Do you:

Summary

Details

Andrew asked in Issue 2050 why the word 'complex' was used in the definition of perimeter.

Andrew also provided PR 2051 to remove it.

We could also remove the other words, so that it says:
"continuous line forming the boundary of a shape not including shared pixels, or the minimum bounding box, whichever is shortest."

Do you:

Summary

Details

From an issue originally raised by Michael Gower, Issue 2017 asks whether large editing areas should have an exception.

There is a response in the thread basically saying no.

Do you:

Summary

Details

Jake raised Issue 2037 saying that focus-appearance should be under the Perceivable category.

It is quite easy to change from an editorial point of view, just a little odd to separate it from 2.4.7.

Should we:

Summary

Details

Michael raised issue 1929 on the relation to non-text-contrast.

The 'adjacent' bullet has already been updated in a question above, so PR 2060 focuses on the understanding document. It makes a significant update, removing the examples with checkboxes, and putting in a simpler example of something which would pass non-text contrast, but fails this SC.

Do you:

Summary

Details

Previously we had closed Issue 1328 by including a section of the understanding document which said that links split over lines could be treated as one area.

However, Michael Gower raised that in the majority case (outlines) this was not the case, and crucially it doesn't align with the logic of the boundary box. PR 2040 implements a change to reverse that logic.

Do you think we should:

Summary

Details

Michael Gower raised Issue 1928 suggesting a re-wording of the shape bullet.

The proposed response summarises that: A previous issue (1806) triggered a change to the bullet which appears to address the issue. Also, the suggestion in 1928 slightly adjusted the meaning in a way that would prevent some indicators intended to pass.

Do you:

Summary

Details

Andrew raised Issue 1887, concerned about the understandability of the criterion.

The response in the thread says: After PR 2000 introduced a new part of the intent aimed at providing simple examples, this issue could be closed. The group will remain responsive to improvements.

Summary

Details