Add Obscure to 2.4.11 Focus Visible (Enhanced)

[mbgower]

To address #952, this proposes an additional fourth bullet being added to 2.4.11, which would read:

Unobscured: The focus indicator is not entirely hidden by author-created content.

The entire SC would then read:

Success Criterion 2.4.11 Focus Visible (Enhanced)
When a User Interface Component displays a visible keyboard focus, all of the following are true:

• Minimum area: The focus indication area is greater than or equal to the longest side of the bounding rectangle of the focused control, times 2 CSS pixels.
• Focus contrast: Color changes used to indicate focus have at least a 3:1 contrast ratio with the colors changed from the unfocused control.
• Contrast or thickness: The focus indication area has a 3:1 contrast ratio against all adjacent colors for the minimum area or greater, or has a thickness of at least 2 CSS pixels.
• Unobscured: The focus indicator is not entirely hidden by author-created content.

Rationale:
This wording requires the author to take responsible for keeping at least a portion of the item with focus within view, if they have added content that can potentially obscure it. This will cover items such as sticky footers, but will not cover user agent-caused issues such as when a small portion of the lower left screen is obscured by user agent exposure of a link target.
This will also not result in a failure due to user agent zooming enlarging the item with focus so that it does not fit within the current viewport.
The "entirely hidden" language is an example of "perfect" not being the enemy of "good". It provides flexibility, while still resulting in a clear pass/fail. As long as some part of the focus indicator is not obscured by author-created content, it passes. It's not ideal, but it is very clear, and it will have a demonstrable improvement for anyone navigating by keyboard.
This addition was created because there was consensus that an obscured item with focus does negatively and strongly affect users with disabilities and SHOULD be a failure, but was not a failure of any current SC.

[alastc]

The "not entirely" works to remove conflict with the first bullet (how big is the indicator).

I'm a little worried bit "author-created content" though, because one of the issues I see sometimes (that should still be covered) is when focus indicators are 'clipped' by nearby content. E.g. buttons overlap each other, or links within a wrapper that hides the focus indicator.

I wonder if it is worth bringing in a concept of layers, a bit like Content on hover/focus. E.g.

• Unobscured: The focus indicator is not entirely hidden by author-created content based on scroll position.

Hmm, no, not good enough, but do you know what I mean?

[JAWS-test]

My question would be whether we should not also consider when the focused element is not at all obscured by author-generated content, but is simply not scrolled into the visible area. This is also often seen. I.e. the element itself and the focus would actually be visible, but the scroll position is wrong.

[detlevhfischer]

Another question is how to evaluate content in situations where there are temporary fixed-position elements at the bottom of the page that need to be dismissed/okayed, like the ubiquitous cookie dialogues. Sometimes they’re hard to get to with the keyboard because they’re attached at the end of the document - this seems a clear failure of 2.4.3 Focus Order, but would it also fail Focus Visible (enhanced) if this 4. bullet is added?

[detlevhfischer]

And thinking of Bruce’s recent survey of opinions on whether Focus Order covers reverse tabbing, I wonder whether the fourth bullet would not also implicitly cover the ofen-used fixed position headers - the focus can just as well disappear behind them when tabbing backwards.
Here, we may have FAIL conditions in desktop viewports with fixed headers, and PASS conditions in cases where authors have followed our advisory Technique and have unstuck the header at narrower viewports. The mere fact that we have a Technique that tells people to unstuck headers would sit uneasily with a requirement that would make fixed position headers fail a new SC.
In sum, there are so many issues that are raised by adding the fourth bullet that it seems likely that it could delay or prevent the introduction of the new SC. Therefore I recommend postponing it or putting it into a new SC.

[alastc]

should [we] not also consider when the focused element is not at all obscured by author-generated content, but is simply not scrolled into the visible area.

Surely that's a user-agent issue? I really don't want to encourage people to takeover the scrolling mechanism in browsers for this issue. It generally works, can you point to an instance that doesn't involve layers of content above the focused element, or deliberately hidden off screen?

how to evaluate content in situations where there are temporary fixed-position elements at the bottom of the page that need to be dismissed/okayed, like the ubiquitous cookie dialogues.

Hmm, I would have thought that comes under the same principle as those which are not dismissable, however, would the dismiss version be a 'mode of operation'?

I wonder whether the fourth bullet would not also implicitly cover the ofen-used fixed position headers - the focus can just as well disappear behind them when tabbing backwards.

Yes, that's been part of the conversation about this. Testing would need to be both forward and backward, in different page variations.

The mere fact that we have a Technique that tells people to unstuck headers would sit uneasily with a requirement that would make fixed position headers fail a new SC.

Well, an unstuck header would pass. Also, we can add a technique about scroll-padding to keep the focused element in view. It isn't perfect, I think it would have to be advisory, but it generally works.

there are so many issues that are raised by adding the fourth bullet that it seems likely that it could delay or prevent the introduction of the new SC

I think it's worth a discussion, falling back to not including it.

[JAWS-test]

Surely that's a user-agent issue? I really don't want to encourage people to takeover the scrolling mechanism in browsers for this issue. It generally works, can you point to an instance that doesn't involve layers of content above the focused element, or deliberately hidden off screen?

The browsers always scroll correctly. The errors are therefore always made by the web authors, but not always in a way that author-generated content obscures the focus. Which happens much more often in my test practice:

• the focused standard element (such as radio button, checkbox, drop-down list) is not displayed, instead they display a custom made, separate element where the focus is also correctly visible. But since the focused element is not always below the visible element, the browser scrolls the focused element correctly, but not the visible element (see https://jsfiddle.net/krpnzgue/4/)
• when using aria-activedescendant, the focused element is also often not scrolled into the visible area. I have already mentioned an example in Sticky headers/footers violation of SC 2.4.7? #952 (comment)

[mbgower]

because one of the issues I see sometimes (that should still be covered) is when focus indicators are 'clipped' by nearby content.

@alastc This is what I meant by perfect not being the enemy of good. What I have proposed will NOT resolve every issue to do with author-created oddities. But it will ensure that at least part of the item with focus will remain visible, where the obstructing item is caused by the author. Any more than this, and it becomes extremely difficult to have a clear test. My hope and expectation is that this bullet will cause items that obscure any part of the focused element to receive more attention by the author. Other guidance does cover considerations when non-focused dynamic content partly obscures other content (thinking Content on Hover or Focus here).

[mbgower]

@JAWS-test A real caution I've found with new SCs is trying to do too much with one SC. @detlevhfischer is already raising the concern with the new bullet, even constrained as it is.

So my strategy here is not to ask what this does not cover, but what the new bullet does cover. Does it add additional value to the current wording of 2.4.11? My feeling is "absolutely," so I think a better (or at least more focused) discussion here is where Detlev is going: are there things that would fail from this new bullet which we don't want failing?

[mbgower]

@JAWS-test
as you note in your comment, what you describe is not occurring as a result of authors obscuring the item with focus with other content, therefore it wouldn't apply.

(By the way, the example you gave seems to reposition for me. If I have my screen magnified and the button positioned near the bottom of the page, the descendants reposition to all be visible.) Don't want to digress here, as I understand what you are describing. End point from me is that that is another consideration. Not covered (intentionally) by this bullet.

[mbgower]

Another question is how to evaluate content in situations where there are temporary fixed-position elements at the bottom of the page that need to be dismissed/okayed, like the ubiquitous cookie dialogues.

Let's be clear, here, @detlevhfischer. When it appears, a dialog takes focus. As soon as that happens, the prior item with focus no longer has focus. The phenomenon of something new taking focus does not therefore cause a failure of this new bullet.

In a situation where a non-modal dialog allows focus to leave the boundaries of the dialog box but the dialog does not disappear and as a result fully obscures the item with focus, it would (and should) fail this bullet.

If the cookie notice element you are talking about is not a true dialog box and does NOT take focus AND obscures the item with focus, then yes, it would (and should) fail this.

[mraccess77]

@mbgower and others - the situation I am thinking of is a non-modal dialog at the bottom of the screen for a cookie notice. The notice stays up until you dismiss but does not restrict focus. The notice can be dismissed or left up. The notice will obscure focused content behind it when not dismissed. The user is able to dismiss the notice with the keyboard. Is this a fail because it requires user action to dismiss or is it a pass because the user can dismiss it. This situation happens to me frequently.

[mbgower]

@mraccess77 I understand what you are describing here, and I believe, depending on implementation, these are exactly like sticky footers that initiated this entire discussion. I've seen some that gracefully stay at the bottom of the page and never obscure content, and some that do. As this bullet is written, if that cookie notice is non-modal and is not coded to reposition down the page as the focus moves down the page, it would fail this. (And, BTW, many of these are not easily dismissed by the keyboard, in my experience.)

[awkawk]

@mraccess77 This is designed to be a little in the way, in my opinion, so I would characterize this as working as designed for all users, and the fact that it obscures focus may not be ideal for the user but as long as the user doesn't need to traverse the obscured items to be able to dismiss the non-modal dialog I would hope that this is ok.

[mraccess77]

@mbgower I'd be fine with it failing that bullet as the mouse user is able to read the page without accepting the cookies. Many of these don't have a decline option - only an accept or options or accept button -- keyboard users shouldn't be forced to accept cookies just to see the keyboard focus whereas a mouse user could get around accepting the cookies. I run into this issue frequently even when keyboard focus is not obscured because the notice takes up so much real estate on a zoomed in page it's difficult to read without being forced to accept these.

[mbgower]

@awkawk I don't know about you, but I find these cookie notices pretty annoying (as implemented). I think the practice started because it was an imposed requirement, so authors didn't want their designs disrupted and shoved this non-modal dialog at the bottom. I understand the motivation, but the practice is indistinguishable to me from other sticky footers, and I think there is demonstrable negative impact on some users with disabilities.

As written, this bullet would require authors to properly handle the sticky footer, or resort to a one-time real cookie dialog where they wanted to use them.

[mraccess77]

I've also seen situations where focused content is not scrolled into view and if it's totally obscured I'd consider it a fail of this proposed SC. Typically this could happen content that is floating, anchored at the bottom, or top, etc. but that is not dismissable or when scrolling content is within the page. The examples of @JAWS-test with aria-activedescendant and visual focus indicators that are separate from system focus (e.g. canvas or custom drawn indicators) are classic examples but I could imagine this might happen other ways as well in different technologies outside of web.

[awkawk]

@mbgower I find them annoying too, that is part of their job. I don't like it, but that doesn't make it an accessibility issue.

That said, when I visit a site like https://www.theguardian.com/us a mouse user can scroll the top part of the content but keyboard users have the focus slip behind the cookie notice, so it does seem unequal... I'll think about this more.

[mbgower]

@awkawk Yep, I want to distinguish between the lousy reduced viewable area @mraccess77 is partly talking about and the Guardian page, where the footer obscures the keyboard focus. I'm only addressing the latter with this criteria.

The inability of a user to get to that warning by keyboard and the reduction of the viewport are the kind of antagonizing issues that would at least be partly addressed if the material allowed graceful scroll down for keyboard users.

[alastc]

To repeat a comment from above about the cookie banners: I would have thought that comes under the same principle as those which are not dismissable, however, would the dismiss version be a 'mode of operation'?

I.e. does the fact that you can (eventually) dismiss it mean there is a "mode of operation" where the focus is visible?

[mbgower]

I.e. does the fact that you can (eventually) dismiss it mean there is a "mode of operation" where the focus is visible?

@alastc, not sure if your question is posed in the abstract or not. For the Guardian specifically, the keyboard focus when I just checked BEGAN in the 'Your privacy' cookie notice. So I have the ability to choose the "I'm okay with that" button to dismiss and proceed. I also have the ability to tab right past it and into the body of the page (with the cookie overlay remaining). At that point, to me this non-modal (which I'm showing a in a screen snippet following this paragraph) will fail the new bullet. It is EASY to resolve this. For instance, when the user tabs out of the non-modal region, the non-modal should cease being sticky. It should dismiss (could then become affixed content in the footer or whatever).

Incidentally, if I choose the Options button, which is visible in the Your privacy overlay that precedes this paragraph, I experience an even better example of why I think this new bullet is so important.

The Options 'dialog' appears (shown in next screen shot), and it is constructed visually as a modal dialog, with a 'save and close' and 'cancel' buttons. However, it is actually non-modal, and I can tab right out of it and put my focus on the page. This should never be allowed, but where to fail it in WCAG has always been unclear. (I welcome where folks do it now... I usually use Focus Order). This bullet in Focus Visible (Enhanced) provides a clear failure point now.

Getting back to your mode of operation question, if you were asking in the abstract, I think in regard to 2.4.7, it's another thing you'll likely hear disagreement about. Our prior conversation was about the ability to use arrow keys to scroll the item with focus into view. For the Guardian page, I still have that ability of 'scrolling down.'

In regard to your discussion on reaching it, the ability to reach the item by keyboard and dismiss it would be a technical pass of 2.1.1 Keyboard, as would a failure if you couldn't get to it. If I couldn't scroll down to expose the focus item and had to resort to tabbing a whole bunch of unexposed times to dismiss the blocking item, I hoped we'd all agree that's a horrible experience! Regardless, the "mode of operation" text is not part of 2.4.11, so doesn't enter into the discussion, right?

[alastc]

@mbgower - I'm don't think I've explained it very well, what I mean is:

Is the initial state (with the cookie banner) one mode, and when you've dismissed the the banner another mode? Therefore there is a 'mode of operation' which shows the focus. It is a rubbish experience to get there (if the banner is at the bottom of the source code), but I could see that line of argument.
If the intent is no, we'd have to clarify in the understanding.

Separately, I am very concerned that the "Unobscured" bullet allows for focus styles which are cut-off by their sibling. Without it, they would be fully covered by the new SC, particularly the first bullet on sizing.

For example, if a link has a proportion of it's focus indicator hidden by a sibling or wrapper, you'd have to work out if it still has sufficient area to be equivalent to a 1px border. With the new bullet it would pass because some is still showing.

As a slightly contrived example (because I had to add the focus indicator myself!), Gmail would cut-off the indicators on quite a few links where they are within a panel, but it is nothing to do with scrolling:

With the new bullet, we are back to only a small indicator passing if it is cut-off due to odd layout, is that worse than not covering sticky footers?

I would rather restrict it to the scrolling context, somehow.

[mbgower]

@alastc

For example, if a link has a proportion of it's focus indicator hidden by a sibling or wrapper, you'd have to work out if it still has sufficient area to be equivalent to a 1px border. With the new bullet it would pass because some is still showing.

The bullets in Enhanced are not "1 of" they are "all of", so passing the obscured bullet does not resolve failures of the other bullets.

The author needs to confirm their styling achieves the first bullets, then needs to confirm their other content doesn't fully obscure that styling.

Or am I misunderstanding what you're talking about?

[JAWS-test]

Why can't instead of writing

Unobscured: The focus indicator is not entirely hidden by author-created content.

write:

Unobscured: The focused element and the focus indicator are in the visible area.

And in the Understanding could be explained

• does not apply to browser errors (the errors I mentioned and which occur frequently are not browser errors, as has now also been noticed at APG: Comboboxes should consider window border when opening, or they should scroll automatically aria-practices#1420)
• applies to the focus indicator or parts of the focus indicator that are large enough to meet the other conditions
• applies to the entire element. If the element is too large for the viewport, however, as much as possible should be visible (from the beginning in relation to the reading direction, i.e. from the top left for English pages)

[mbgower]

@JAWS-test

why can't write "Unobscured: The focused element and the focus indicator are in the visible area."

Because the SC text must be measurable and testable, and because authors cannot control things like a user's magnification or text resizing settings. It is entirely possible without even significant magnification to end up with a element with focus that is not entirely in the "visible area".

The "author content" wording restricts obstructions to only things covering the item with focus -- for which the author is responsible -- as opposed to the item with focus falling parlty outside the viewable region. The "entirely hidden" phrase ensures that the fail is clear, and testers do not have to resort to a judgement.

[mraccess77]

WCAG 2.1 does require conformance with variations of pages - so each variation would need to be tested although within each variation zoom levels can vary with resolution and there are a huge number of things to test -- so I"d imagine that within variations we would likely not be able to control every possible situation.

[JAWS-test]

@mbgower

Because the SC text must be measurable and testable, and because authors cannot control things like a user's magnification or text resizing settings. It is entirely possible without even significant magnification to end up with a element with focus that is not entirely in the "visible area".

Unfortunately, I am not convinced by this argument:

1. the WCAG criterion applies to the standard view, without magnification
2. there are, as I have described, many errors of the authors which lead to the element and focus not being visible without the element being hidden by author-generated content. Instead, the element is generally outside the visible area
3. as I wrote above: my suggestion is that the element must be in the visible area. If the element is too large for the visible area, it does not have to be completely in the visible area
4. if the WCAG SC 2.4.11 allows in the last point that the focus is only partially visible, the other points from SC 2.4.11 may not be fulfilled, i.e. the focus indicator is too small. This would be a contradiction within SC 2.4.11
5. A focus which is not or poorly visible is bad for keyboard users and visually impaired users. But how much worse is it for these users if the focused element is not visible at all and cannot be scrolled into the visible range. If this is not covered by any WCAG SC, this would be a big gap

[alastc]

I'm going to discuss 'mode of operation' in the other thread (#1067) , this is about un-obscured.

I made a test case that shows both types of issue I've been talking about:

1. The text links should be mostly kept in view whilst scrolling down, at least in chrome/edge (not FF).
2. The image links are having their indicator cut-off by overflow: 0 and lack of padding.

I see the second more often than sticky footers, especially with my own focus styles applied, it is very common on 'card' type components.

I think the second example (permanently partially hidden) should fail (assuming it doesn't meet all the other bullets), but it appears to be covered by:

Unobscured: The focus indicator is not entirely hidden by author-created content.

The surroundings of the image-links are author created content, it is not 'entirely hidden', it really looks like an exception. If it isn't an exception for 2, I don't see how it covers 1 (in a scenario when none of the indicator is shown).

I'd like to say something like:

• The focus indicator is not entirely hidden by author-created content that varies on scroll, or
• The focus indicator is not entirely hidden by author-created content on a different layer

or something, some qualifier that it is about different layers of content or something...

[alastc]

Hi @JAWS-test,

the WCAG criterion applies to the standard view, without magnification

Not really, you should test page variations which essentially covers zoom, and you should text text-spacing (for example) in each variation. It isn't exactly asking for testing magnification, but it's close.

there are, as I have described, many errors of the authors which lead to the element and focus not being visible without the element being hidden by author-generated content. Instead, the element is generally outside the visible area

If you mean the two in the comment above:

• Custom controls where the actual focusable element are hidden is an interesting case (assuming it shows an indicator, but the control may not be scrolled into view). That does relate closely to the sticky-elements case.
• For aria-descendent examples, I'm not convinced that is something the author should handle, it seems to be a missing feature in the browser.

as I wrote above: my suggestion is that the element must be in the visible area. If the element is too large for the visible area, it does not have to be completely in the visible area

I'm not clear what 'visible area' would constitute? I think you'd end up saying it 'must be visible', which is what all the other bullets are defining. What we need is to clarify in what circumstances it can be partially hidden.

if the WCAG SC 2.4.11 allows in the last point that the focus is only partially visible, the other points from SC 2.4.11 may not be fulfilled, i.e. the focus indicator is too small. This would be a contradiction within SC 2.4.11

In the current phrasing, I agree.

A focus which is not or poorly visible is bad for keyboard users and visually impaired users. But how much worse is it for these users if the focused element is not visible at all and cannot be scrolled into the visible range. If this is not covered by any WCAG SC, this would be a big gap

If it cannot be scrolled into range, that is covered now.

[JAWS-test]

Hi @alastc,

the WCAG criterion applies to the standard view, without magnification

Not really, you should test page variations which essentially covers zoom, and you should text text-spacing (for example) in each variation. It isn't exactly asking for testing magnification, but it's close.

I meant enlargement with AT like ZoomText, Windows screen magnifier or SuperNova. Although I think it is important that this kind of AT is better supported by the WCAG. I think, this could be achieved, for example, by the WCAG requiring that the programmatically transmitted position of an element (UIA: BoundingRectangleProperty) matches the actual position.

According to CC 5.2.2 Full pages each WCAG SC must be fulfilled for all screen widths. But I wonder whether each WCAG SC must actually be satisfied in combination with modified text spacing? Where does it say that?

Custom controls where the actual focusable element are hidden is an interesting case (assuming it shows an indicator, but the control may not be scrolled into view). That does relate closely to the sticky-elements case.

Unfortunately these elements are not covered by the current wording, as the focus is not obscured by author-created content. That is why I continue to be very much in favour of not restricting the wording to author-created content, but generally demanding that the focus and the focused element must be in the visible area. If there is agreement on this, I am happy to propose a formulation regarding the completeness of visibility for large (e.g. multi-line) elements.

For aria-descendent examples, I'm not convinced that is something the author should handle, it seems to be a missing feature in the browser.

That is not true, in my view, because a basic principle of ARIA is that it has no effect on visual representation. Furthermore, the selection lists with aria-activedescendant were only one example. Not everyone uses this ARIA attribute and even without the ARIA attribute, the focused items should be visible.

If it cannot be scrolled into range, that is covered now.

By which formulation is this now covered?

I have tested hundreds of pages for WCAG over the last years and found that about 10% of the pages had the problem that the focused element was not visible. Main problems are:

• Fixed areas
• Elements with aria-activedescendant
• hidden standard elements that get the focus, where the visible focus is on a custom element

Recently the problem has increased significantly, about 30% of the pages I've checked would violate this. The reason is that many frameworks and designers use custom elements (see also the survey https://gwhitworth.com/surveys/controls-components/)

[mraccess77]

I think what @JAWS-test might be saying is that if we allow for partial focus indicators then that undermines the text of the SC itself. How can a partial indicator meet the size requirements called for. It seems to me that we are only allowing partial in certain specific situations where the rectangle would otherwise be drawn but for some reason is covered but if the covering was removed the rectangle would then meet the SC criteria. Perhaps we could clarify with similar text.

[alastc]

According to CC 5.2.2 Full pages each WCAG SC must be fulfilled for all screen widths. But I wonder whether each WCAG SC must actually be satisfied in combination with modified text spacing? Where does it say that?

You answered it there, text-spacing must work under each screen width. See also #391 for discussion of that.

a basic principle of ARIA is that it has no effect on visual representation.

I'm not sure why that is relevant. If an element gets focus, regardless of the ARIA markup, it should be scrolled into view by the browser.

AC: If it cannot be scrolled into range, that is covered now.
By which formulation is this now covered?

If something is off screen and cannot be view whilst focused then we generally fail that under focus-order. (Loosing meaning due to not being visible at the correct point.) In recent calls a few people had mentioned that they did that as well.

if we allow for partial focus indicators then that undermines the text of the SC itself. How can a partial indicator meet the size requirements called for.

That's my concern as well, it looks like an exception in the current form, I'd like it to be more specific, but struggling with the wording for that.

[JAWS-test]

I'm not sure why that is relevant. If an element gets focus, regardless of the ARIA markup, it should be scrolled into view by the browser.

The special thing about aria-activedescendant is that the element focused by the browser (e.g. the container or the input field) is not identical to the element that has the visual focus (e.g. the list entry). Exactly this behavior then causes the problems that occur even in the ARIA APG example.

If something is off screen and cannot be view whilst focused then we generally fail that under focus-order.

I'd be perfectly happy with that. However, in my opinion, there is currently no indication in SC 2.4.3 that the problem is part of it. Can the Understanding be adapted? In terms of content, however, the problem would fit better with SC 2.4.7 or SC 2.4.11.

[alastc]

Mostly for @mbgower I came across another example of partial focus indicator on a site today.

NB: The site had no real focus indicator so I turned on my stylus "power focus indicator", and on the top menu got this for the top row:

(The top of the indicator is cut off, it isn't just a cropping of the screenshot!)

And for sub-menu items the top & bottom are cut off:

So my concern is that someone would apply standard 1 or 2px outline styles to the focused element, read the new bullet point and think: well, that's ok then.

[mbgower]

NB: The site had no real focus indicator so I turned on my stylus "power focus indicator", and on the top menu got this for the top row:

if the site had no real focus indicator, then it fails 2.4.7. An add-on is kinda fudging the results.

So my concern is that someone would apply standard 1 or 2px outline styles to the focused element, read the new bullet point and think: well, that's ok then.

I don't understand this. The 4 bullets are "All" not "or". Passing bullet 4 does not stop one from needing the other bullets. This seems to me to be easy to address in the Understanding document. The first three bullets cover elements of how the visibility is implemented on the control with focus. The fourth bullet says 'now that you have these enhancements', you can't entirely cover up the item with focus in the viewport.'

[mbgower]

@alastc in your demo and comments, you continue to seem to treat the enhanced bullets as "or" statements, but they are "and" statements.

Passing the 4th bullet does not pass the SC. It just passes the 4th bullet. You still have to meet the other 3 bullets. So I fail to see why you want to modify the 4th bullet. You don't need to for your images to fail (assuming they fail one of the other 3).

[mbgower]

@mraccess77 and @alastc does this better address your concern?

Unobscured: The item with focus is not entirely hidden by author-created content

I believe that changing the wording to "item with focus" reduces the confusion talked about in this passage?

I think what @JAWS-test might be saying is that if we allow for partial focus indicators then that undermines the text of the SC itself. How can a partial indicator meet the size requirements called for. It seems to me that we are only allowing partial in certain specific situations where the rectangle would otherwise be drawn but for some reason is covered but if the covering was removed the rectangle would then meet the SC criteria. Perhaps we could clarify with similar text.

In my opinion, given this is an "all of the following are true", all 4 bullet need to be met, and to the degree that the 4 bullets' scenarios need to be explained, that can be covered in the Understanding doc. But I believe this slight rewording makes the difference much clearer?

[alastc]

As of the call today, this bullet has been added to the SC text:

Unobscured: The item with focus is not entirely hidden by author-created content

And there is a small update to the understanding doc to explain it:
bedbdda

Closing as decided, but please re-open if something is not addressed.