Re: { Sticky Bar } 400% & Keyboard Navigation

After the Reflow criterion, the web has improved considerably, but sticky
objects are the biggest obstacle of using web pages today. I think they
should all be collapsable no exception. This is especially true for text
heavy pages.

If the page presents textual content like Stack Overflow or the W3C, then
obstruction is significant. At 400% you get at most 15 words per page. If
you are considering a page that exists to communicate information, then a
30%  loss means that you reduce essential content to less than 10 words.
50% and you have reduced essential content to less than 8 words per page.
That is more than a little difficult.

In well constructed pages like Stack Overflow and W3C pages these issues
are easy to fix, but less professional sites make removal very difficult.

I think the problem is that these pages fail to operate in landscape mode.
They assume that low horizontal size means portrait mode and they have
plenty of room for a large sticky element.

In any case, users should have a way to make sticky elements go away
without having to hack the page.

I believe that a page whose main function is to convey written content will
fail when 30% of the page is taken by sticky objects.

When more than that is taken then the reader must plow through an article 2
lines at a time where each line holds between 3 and 4 words. Nothing is as
bad as horizontal scrolling, but 2 lines per page is very disruptive. If I
can't hack a page like that, I just don't read it.
Best Wayne



On Tue, Mar 2, 2021 at 11:56 AM Chris O'Brien <chrobrien@olg.ca> wrote:

> Unfortunately, what we test is not always decided upon one group
> unilaterally. Once again. I don't disagree with anything you've said, but
> it's not always that easy to simply force changes in methodology broadly.
>
> Chris O'Brien
> Director of Accessibility
> Legal and Litigation
>
>
> OLG Internal
>
> -----Original Message-----
> From: Steve Green <steve.green@testpartners.co.uk>
> Sent: Tuesday, March 2, 2021 2:46 PM
> To: Chris O'Brien <chrobrien@olg.ca>; w3c-wai-ig@w3.org
> Subject: RE: { Sticky Bar } 400% & Keyboard Navigation
>
> This email originated outside of OLG. Do not open attachments or click
> links unless you recognize the sender and know the content is safe.
>
> It's important to keep things in perspective and choose the battles you
> can win. Even if you managed to force through your viewpoint on this issue,
> it only takes you a little way beyond strict level AA conformance. But you
> still won't meet almost any of the level AAA success criteria. And then
> there are all the accessibility issues that are not even addressed by WCAG
> at all.
>
> Getting your own way on this issue isn't the difference between your
> website being 99% or 100% accessible. There will still be lots of
> accessibility barriers for some people. It's just that you have chosen to
> limit your testing to a level that doesn't reveal them. If you tested for
> level AAA conformance or did assistive technology testing or did user
> testing with disabled participants, you would find a whole load more issues.
>
> We find that evidence from user testing is a lot more persuasive than WCAG
> test results even when they say the same thing, so maybe you can use that
> approach to bolster your argument. As long as the user testing results
> actually turn out like you hope and expect.
>
> Steve
>
>
> -----Original Message-----
> From: Chris O'Brien <chrobrien@olg.ca>
> Sent: 02 March 2021 19:33
> To: Steve Green <steve.green@testpartners.co.uk>; w3c-wai-ig@w3.org
> Subject: RE: { Sticky Bar } 400% & Keyboard Navigation
>
> I don't disagree with either of you. It's just a hard sell in many cases
> for stakeholders only interested in compliance only. The subjectivity can
> be problematic in these cases.
>
> Chris O'Brien
> Director of Accessibility
> Legal and Litigation
> 416.224.7769
>
>
> OLG Internal
>
> -----Original Message-----
> From: Steve Green <steve.green@testpartners.co.uk>
> Sent: Tuesday, March 2, 2021 2:05 PM
> To: w3c-wai-ig@w3.org
> Subject: RE: { Sticky Bar } 400% & Keyboard Navigation
>
> This email originated outside of OLG. Do not open attachments or click
> links unless you recognize the sender and know the content is safe.
>
> I totally agree with Patrick. To answer the question, you need to decide
> what's important to you (or whoever's decision it is).
>
> If you only care about strict WCAG conformance, then all that matters is
> whether any content is completely hidden at 400% zoom.
>
> If you care about the user experience, then you can pick your own
> percentage cut-off level. There is no "right" answer, but I usually advise
> our clients to unstick the sticky content when it reaches about 25% of the
> viewport height.
>
> Steve
>
>
> -----Original Message-----
> From: Patrick H. Lauke <redux@splintered.co.uk>
> Sent: 02 March 2021 16:29
> To: w3c-wai-ig@w3.org
> Subject: Re: { Sticky Bar } 400% & Keyboard Navigation
>
> On 02/03/2021 16:08, Chris O'Brien wrote:
>
> > Question regarding the above: in your opinion what is the threshold?
> > This pattern presents significant challenges during reflow, and works
> > directly against those who need this accommodation (as you know). I
> > find this one particularly frustrating because it is clearly an
> > anti-pattern yet is it relegated to advisory status.
>
> One follows from the other really: there's no easy-to-agree-on hard
> cut-off point where you can say "if it covers X% of the content, this is a
> fail, otherwise a pass", unless we make up an arbitrary number (which makes
> little sense, since it would then lack any kind of nuance ... what if
> something only covers a very tiny amount of content, but THAT particular
> bit of content is actually really (subjectively) important to the user?
>
> Because it's not a simple binary value that can be agreed on, it's much
> tougher to make it a hard fail condition. Arguably, when things like this
> have been decided in the past (say, the cut-off for what is good vs bad
> color contrast), there's always edge cases where failing/passing just seems
> very arbitrary...
>
> P
> --
> Patrick H. Lauke
>
>
> https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.splintered.co.uk%2F&amp;data=04%7C01%7Cchrobrien%40olg.ca%7Cf631e7bdfb5c4055b3a808d8ddb3e19b%7Cf271d9b4e54c46e182bd25d50afa3779%7C0%7C0%7C637503111956246743%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=iUTIj4TKy9KJmaJqrOzJlE6r24XMachplge%2BXU0aSc8%3D&amp;reserved=0
> |
> https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fpatrickhlauke&amp;data=04%7C01%7Cchrobrien%40olg.ca%7Cf631e7bdfb5c4055b3a808d8ddb3e19b%7Cf271d9b4e54c46e182bd25d50afa3779%7C0%7C0%7C637503111956246743%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=5MSnYvHK75AgRdYaJ%2FqtdWNyoxuGfbL5TENV8A9lbSU%3D&amp;reserved=0
> https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fflickr.com%2Fphotos%2Fredux%2F&amp;data=04%7C01%7Cchrobrien%40olg.ca%7Cf631e7bdfb5c4055b3a808d8ddb3e19b%7Cf271d9b4e54c46e182bd25d50afa3779%7C0%7C0%7C637503111956246743%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=%2FKZgMWAkljVAuDDkwqxIMp53s7poRe2cLSCautI8yiA%3D&amp;reserved=0
> |
> https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.deviantart.com%2Fredux&amp;data=04%7C01%7Cchrobrien%40olg.ca%7Cf631e7bdfb5c4055b3a808d8ddb3e19b%7Cf271d9b4e54c46e182bd25d50afa3779%7C0%7C0%7C637503111956246743%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=L0GSYdLFfkUqllAfxn0MuO7NPSbdaATV2WjYeZgu1GE%3D&amp;reserved=0
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
>
>