I support the intention of the proposal. However, this has already been discussed in detail: #1145. Full visibility cannot be demanded, because some elements are too large and do not fit into the viewport. Therefore I had suggested an alternative wording: See #1145 (comment). However, I am afraid that the concerns are no longer taken into account.

Hi @guyhickling,

There was quite a lot of discussion about this issue, particularly in #952

One of the core problems is that it is not entirely under the authors control as to how much of a link is shown as you tab down a page.

For example, if I tab down a github issue list lots of the links are partially hidden by the status (URL of the target page):

If you have a sticky header/footer you can use scroll-padding or similar to buffer the top/bottom. However, if the user zooms in, or adjusts text-spacing so that something inside the header/footer wraps, there is no mechanism to updatethe height of the padding.

We did consider whether it would be useful to say 50% or something, but it seems very fiddly relative to the positive impact. (Particularly when people were already commenting on the maths involved for this SC.)

One of the core problems is that it is not entirely under the authors control as to how much of a link is shown as you tab down a page.

The problem could have been explicitly excluded: If the browser hides contents, the author is not responsible for it. It is a pity if this one browser problem is used as an excuse to formulate the SC meaningfully.

If you have a sticky header/footer you can use scroll-padding or similar to buffer the top/bottom. However, if the user zooms in, or adjusts text-spacing so that something inside the header/footer wraps, there is no mechanism to updatethe height of the padding.

That's not true. The fixed header or footer can have an absolute height, which is adjusted when zooming. With some space in the header and footer, text spacing can also be adjusted. You should also consider whether the header and footer should no longer be fixed when zooming in order to see enough content (see #987)

My main problem, however, is the phrase "author-created content". The focus and the focused element may not be visible for many reasons, e.g. because they are outside the viewport without being covered by author-created content

@JAWS-test

That's not true. The fixed header or footer can have an absolute height, which is adjusted when zooming. With some space in the header and footer, text spacing can also be adjusted.

Not reliably, esp when the content inside can wrap unpredictably (and especially if this happens from Text Spacing changes OR enlarging text-only like in Firefox-- you can use CSS media queries if based on (r)em to catch font growth but not if Text Spacing causes more wrapping). You can have a onResize() listener (with major throttling/trampolining) which runs JS to measure the visible height of the sticky area, however unless browsers scroll the page as the user Tabs (and they don't sufficiently, although Mozilla currently has a ticket), you cannot guarantee that the focussed element is visible.

Even without zooming, sticky footers cover links Tabbed to once the browser has already scrolled just enough for the link to be within the viewport (again, the browser does not know that the link is not visible, only that it is within the viewport dimensions). Sticky headers do this with Shift-Tabbing back.

There is talk of browsers always placing focussed elements in the center of the viewport, however I'm not sure how well that works cognitively, and it doesn't solve side-stickies (esp this awful little-video-remains-onscreen thing that YouTube sometimes does now and too many news sites as well).

It means developers with sticky-anythings need to implement something similar to a JS smoothscroll for in-page links, where you must manage the scrolling by hand with JavaScript. For example, adding an onFocus() listener to every single interactive element and highjack it :(

On this topic in general, I'm wondering what the thoughts are for the case of carousels which deliberately half-obscure a clickable card or link in order to give visual feedback to users that there is more content available off to the side. This is often a deliberate technique where users may otherwise not realise there is more content (similar to when a page appears to vertically show all of its content and users don't realise there is more if they scroll down. Apparently this is the cause of those annoying little jumping arrows placed at the bottom of the viewport on pages displaying a viewport-sized hero image).

Apparently the problem is called the Illusion of Completeness?

Edit, better link: NNGroup

If this is so difficult with the fixed headers and footers, my initial question would be: Does the WCAG want to make accessibility possible on an important topic that affects many user groups (focused element is visible when using the keyboard)? If this is the case, it may mean that fixed headers and footers cannot be used until browsers become better or web developers come up with a great solution to the problem. There are also many other WCAG SCs that challenge web developers or force them to abandon cherished elements

True, and I don't know.
Banning sticky stuff seems like a technique that could only be added to an AAA-level SC. I'd rather browsers/user agents fixed it--there's already a scrolling difference between Firefox and the chromium-blinks, I'm just not certain how much compensation they are actually capable of.

@Jawstest: Thank you for the reference to issue 1145. I missed it at the time unfortunately. I am still ploughing through it now (it's a long one!)

I think your alternative wording there would have met the requirement admirably. And you put up a good fight for it. It's a little sad that no one could see a way to accept it because it is the already long-neglected keyboard users who continue to suffer.

The matter of browsers failing to show a component fully could be met perfectly simply by adding a green note below the SC saying something like "The content being obscured as a result of browser positioning errors or browser content is excepted." Or it could even be added as an exception in the SC's text (plently of other SCs include exceptions, so why not this one?)

Components that exceed the size of the viewport would also be an obvious exception.

For sticky headers and footers the solution is very simple. The developer simply gives the main content area top and/or bottom margins that equal the height of the fixed header and footer. I recommend this is as standard in all audits where I have found this issue. (As @StommePoes pointed out above, you have to do this using rem or em units for the margins, not px units, to allow for users using larger text sizes, but that is just a matter of the detail)

I agree wrapping in the header or footer at some zoom/text size settings could be a slight problem. But again the solution is simple:
a) Most websites will cater for that anyway in their media queries. The usual case is when a main menu wraps onto a second line. Most websites handle that by turning it into a hamburger menu before it wraps. (Though they often forget about text spacing and don't set the breakpoint to allow for that unless we point it out to them.)

b) If wrapping does occur, and the designer tests at different screen sizes and decides to allow it, they just have to add another small (2-line) media query to change the main content margin accordingly. Or they can use JavaScript to interrogate the height of the header or footer and adjust the margin to match (that works even if text spacing is present).

As I said above the important point with this SC is that, whatever the situation, if there are sticky headers or footers developers must in any case give their main content areas a top or bottom margin to compensate, or they will fail this SC. The only difference between asking them to show part or all of the focussed component is in the figure they give to those margins.

Finally, issue 1145 spent considerable time discussing cookie messages (privacy and GDPR warnings also sometimes display the same way). If fixed to the top or bottom of the viewport (i.e. non-modal) they are just like sticky headers and footers. While they are showing, just add that amount of height in rem units to the main content margins set for the sticky header/footer. They are closed by JavaScript when the user dismisses them, and that can also remove the extra margin as part of the same processing.

If this is so difficult with the fixed headers and footers.....

It isn't difficult. It is only difficult to those who prefer to object rather than look for solutions!

To build on similar thoughts in #1291:

Not fully obscured by web page content: The item with focus has a visible area that is at least as big as the focus indication area.

It isn't difficult. It is only difficult to those who prefer to object rather than look for solutions!

You're a much much much better developer than I, for I have run into several instances where it's difficult or impossible to compensate reasonably while still keeping the sticky (for this reason, I advocate against stickies, but designers gonna design and higher-ups and marketing often win over developer concerns). The "simply collapse the menu into a hamburger" is fine for menus, but not all stickies are menus. Recently, they are COVID messages. Often you have several breakpoints, since everything from text spacing (this including line-height) to font replacement (user's own font has a different stroke width or kerning? ai) to the innumerable possible viewport widths can all cause multiple edge cases where the difference in height is sufficient to cause your padding to no longer work. It's still almost better to have a constantly-running JavaScript which listens for changes to window resizing and scrolling and re-measuring the displayed height. This can cause non-top-performance machines to act slow or jaggy.

I personally regularly run into web pages where items wrap in a way clearly not intended by the designers/developers due to simply my zoom and OS-font settings, where if I go further in my zooming or font-enlargement, I hit a breakpoint and things "work" again. So these are pages where devs are already using breakpoints and clearly have tested on mobiles or various viewport widths and designers have created correct designs for these other instances.

I'm not certain setting a level of developer ability based on amazing top-level devs with unrestricted resources and time is the right way to go, but I'll sit this one out and let anyone actively working on a not-obviously-easy sticky present their examples, since I have only successfully avoided them by no longer agreeing to code them (but this is my privilege).

You're a much much much better developer than I, for I have run into several instances where it's difficult to impossible to compensate reasonably while still keeping the sticky

I have to concur, @guyhickling you are missing that text-wrapping can change the height of the sticky in a way that you cannot account for in media queries.

Thank you both for those last comments. And I'll just use the term "stickies" from here on for brevity, to cover sticky headers, footers, cookie and other fixed position messages fixed to the top or bottom of the viewport (or fixed to a header or footer that is also sticky).

There have been several references now, in this and the previous issues on the subject, to the idea of advocating against or banning stickies. Stopping them isn't going to happen; they are too popular with designers and too widespread. And many users like them. And it isn't necessary.

What I am arguing for is that instead of saying the problems are insoluble, or impossible to test, or have too many variations, or [whatever other argument], let's instead sit down and try to find a workable way round those problems. There are numerous different ways to cope with problems without banning anything. Sometimes we just have to think outside the box a bit.

First of all, if a particular scenario seems too difficult to fix in an SC we are creating, we can always include an exception. Many SCs have multiple exceptions. In the stickies bullet we could say "except where line wrapping occurs" or similar. That covers were the user's font, or text spacing, or anything else causes unexpected wrapping, but only applies when wrapping is actually triggered in the view as tested (user fonts or spacing don't automatically cause wrapping, that only happens in some cases).

Second, when a certain scenario might seem an insurmountable problem, we should consider how many people are actually affected by it. For instance, user font settings have been mentioned in connection with this issue of stickies. Ok, that's a problem, but how many people change the default font? Around 10% or more of people have dyslexia (figures vary on this, I've also seen 16% quoted by a dyslexia action group. And some other people may change the font as well. But against that, not all people with dyslexia change their font - some people don't know enough about computing to realise they can do that, others know they could but have found it causes unwanted layout display issues so prefer not to. So 10% changing the font seems reasonable.)

But this issue of stickies isn't about people with dyslexia, it's about keyboard users, who are themselves a minority. Keyboard users who also have dyslexia are a minority of a minority. We should not refuse help to a large group just because a smaller subgroup cannot benefit. That's like saying we won't send food aid to a starving country because some of those people have food allergies!

Consider, also, that most improvements are incremental, not one big bang. If we solve this problem now for the majority of keyboard users, we will no doubt find a way to solve remaining issues later, because we will then have something existing to build on. If the inventors of the steam engine had allowed thought of all the problems to stop them, we wouldn't have 400mph bullet trains today! The WCAG has certainly been incremental in many things. We are now on 2.3 and already building v3.

So let's, for a moment, suppose we word the bullet point as:

Unobscured: The item with focus is not hidden by author-created content except where line wrapping occurs.

and see what issues we have remaining. (The matter mentioned above of browser URL displays covering links is already excepted by the words "author-created content". Components larger than the viewport could be be given "or the item is bigger than the viewport" as a further exception, but I don't think that is needed as it is not hiding it by author-created content! - just mention that in the Understanding doc, I think. User zoom is not a problem, that's what responsive design is for...providing developers do it correctly, i.e. not with px units.)

If there are still problems beyond those, perhaps we can find a way to meet them as well. We'll then have a useful rule to help the majority of keyboard users on the majority of websites, rather than the showing just a thin line to indicate something not explained is hidden underneath stickies.

If there is a line wrap in the header or footer due to zooming or adjusting the test distances, the height of the header or footer can remain unchanged - it is sufficient if the header or footer is made scrollable

First of all, if a particular scenario seems too difficult to fix in an SC we are creating, we can always include an exception.

That is the current situation, the last bullet attempts to reduce the impact of sticky elements but the "not entirely hidden" is what allows some wiggle room.

we could say "except where line wrapping occurs" or similar.

How about @StommePoes's example above with carousels? It is a usability benefit to have the last item semi-hidden to show that there are more items, yet that would fail the 'no obstruction'.
The point being that there are a lot of possibilities, and I'm not convinced we have enough breadth of examples to know what should/shouldn't be covered.

We should not refuse help to a large group just because a smaller subgroup cannot benefit.

I agree, but we also shouldn't require that developers create fragile workarounds that make the interface worse for another audience.

If the inventors of the steam engine had allowed thought of all the problems to stop them, we wouldn't have 400mph bullet trains today!

The scenario is actually the opposite, we are more akin to the train regulators where heavy handed regulation could prevent 400mph bullet trains being invented.

Components larger than the viewport could be be given "or the item is bigger than the viewport" as a further exception

So far we need exceptions for:

• The browser not quite scrolling enough
• Items partially hidden by carousel edges
• Items bigger than the viewport (which I don't think is the real issue there, the viewport can change, the content might not)

There would be more exceptions than actual requirement, and I don't think we're close to findings all the 'reasonable' exceptions.

If there is a line wrap in the header or footer due to zooming or adjusting the test distances, the height of the header or footer can remain unchanged - it is sufficient if the header or footer is made scrollable

For me, this is an example of making the interface worse for a different audience.

• The browser not quite scrolling enough
• Items bigger than the viewport (which I don't think is the real issue there, the viewport can change, the content might not)

I personally don’t feel that we need an exception for that. What is outside of the browser viewport is not visible, I think that is clear and logical. We also don't fail people for heading violations when those headings are outside the visible area.

• Items partially hidden by carousel edges

That's why I tried to re-use the focus indication area above: If your card has a 300x300 size, your focus indication area would be 1200px (300+300+300+300) or 2400 (8*300) which is the amount of space you need to have visible. So everything could be obscured but the left (or right, depending on the positioning) four pixels in full height of the element. I think that is a reasonable compromise.

That's why I tried to re-use the focus indication area above:

For clarification, the focus-indication area is the area of pixels which change when focused, not the area of the element.

So a 300 x 300 element with a 1px outline would have a focus-indication area of 4*300 = 1,200 px.

The first 3 bullets target the focus indicator, the last bullet references the whole element (as it stands).

I personally don’t feel that we need an exception for that.

I'm struggling to see the difference, they are all examples where a focus indicator is temporarily hidden. For stickies you need to scroll a bit more to see them (depending on a few factors), same for the carousel example and things which don’t fit into the viewport.

For clarification, the focus-indication area is the area of pixels which change when focused, not the area of the element.
So a 300 x 300 element with a 1px outline would have a focus-indication area of 4*300 = 1,200 px.

Yes, that was also my calculation as above. My suggestion was to say “leave at least an area of the focusable element unobscured that has the size of the focus indication area”.

I'm struggling to see the difference, they are all examples where a focus indicator is temporarily hidden. For stickies you need to scroll a bit more to see them (depending on a few factors), same for the carousel example and things which don’t fit into the viewport.

Some are artifacts of the medium (view ports, scroll positions), others are introduced by special formatting of the web content. WCAG is applicable to the latter, not the former, IMHO.

My suggestion was to say “leave at least an area of the focusable element unobscured that has the size of the focus indication area”.

But what if the control uses a change of background for the focus indication? That would be almost the size of the element, just because a different style is used.

I agree that WCAG is applicable to the content, but these examples are very much in the grey area between that and the user-agent/medium. Even to the extent that you can get differences between browsers in how much of the element would be shown, thus affecting test result.

My suggestion was to say “leave at least an area of the focusable element unobscured that has the size of the focus indication area”.

But what if the control uses a change of background for the focus indication? That would be almost the size of the element, just because a different style is used.

I did not understand that the requirement for the minimum focusable area changes depending on the technique used. I thought (as you have said above) a 300x300px focusable element would have a (3300) = 1200px large minimum focus indication area. My proposal says that an area that is at least as large as this minimum focus indication area. So if you have a 300x300px area, you would need to leave an 4x300px area unobscured. Or a 3535 px square.

It looks like I misunderstood the requirements here, sorry.

Ah, if it's based on the minumum focus indication area, that could work as intended, sorry.

I'm just wondering about the overall benfit (complexity vs improvement) of defining it more than it is is currently.

Hi everyone,

The group agreed this response to this issue, as opened originally: