1

I have a site here: https://wa-leicester.org.uk and I've added a plugin called One Click Accessibility. This provides the little green accessibility toggle on the bottom left of the site.

enter image description here

There only seems to be settings to align the toggle (and its hidden menu) to the top right or top left, so I attempted to align it all to the bottom right of the screen (view area, not the entire page), using the following CSS:

/* icon bottom of nav */
#pojo-a11y-toolbar.pojo-a11y-toolbar-left .pojo-a11y-toolbar-toggle {
    bottom:0 !important;
}
    
/* nav bottom fo screen */
#pojo-a11y-toolbar.pojo-a11y-toolbar-left {
    bottom:20px !important;
}

This seems to work perfectly apart from one thing...

In Chrome, when I click on the Greyscale option inside the menu, the whole thing seems to shoot down to the bottom of the page (seemingly disappearing for the user).

No doubt this is my own doing, missing something with the CSS code, but I can't figure out A: why is moves (it only seems to move in Chrome) and B: how to fix it.

I thought it might have added another class to the toggle OR the hidden menu, but all it seems to do is add a new class to the body tag, to make greyscale with a CSS filter).

Can anyone help? :)

Shaun Taylor
  • 932
  • 2
  • 16
  • 43
  • 1
    It's because the Greyscale option applies a CSS filter property to the body element. Resulting in position:fixed elements to be positioned relatively to the body and no more the viewport. You see the fixed top menu bar is also gone. See this question: https://stackoverflow.com/q/52937708/2409279. If I were you, I would contact the Once Click Accessibility plugin author to fix applying the filter to another parent than body. – Jeroen W Dec 16 '22 at 14:11
  • Ah ok thanks, I guess the next class kind of refreshes the whole body... Might have to think of another solution :) Thanks for explaining – Shaun Taylor Dec 16 '22 at 14:36
  • 1
    It's very important to note that many people who rely on assistive technology to navigate the web **absolutely hate accessibility overlays**: https://overlayfactsheet.com/#in-their-own-words – Sean Dec 16 '22 at 15:38
  • That's interesting - I'm trying not to 100% rely on this - I've tried to aim for AA standard of accessibility, Im still tweaking but its nearly there... this is something the client requested, but it might be worth discussing it with them to see if its really needed - It DOES seem to just get int he way a lot of times! – Shaun Taylor Dec 16 '22 at 15:43
  • @sean, for overlays that purport to **fix** accessibility issues, your comment is correct. However, this plugin tool does not appear to be an overlay. It's just providing some tools to allow changing the font size, grayscale, high contrast, inversion, etc. It's not claiming to fix any accessibility issues so I think this tool is fine to use. The `readable font` option is misleading. It appears to only change the font to `verdana` but who makes the decision that verdana is more readable than the current font? Seems a bit subjective. – slugolicious Dec 16 '22 at 18:20
  • @slugolicious according to the plugin page, it's designed to **fix** contrast issues, missing skip links, links that don't have appropriate signifiers, missing focus styles, and more. It's not just providing additional affordances. – Sean Dec 16 '22 at 20:46
  • @sean, I didn't go to the company page. Thanks for checking that. Do they claim to fix **all** accessibility issues? That's the biggest problem with the overlays mentioned in the fact sheet you posted. They all claim that you don't have to do any accessibility work because their tool will fix everything. That's rubbish and false advertising. The tool mentioned in this question didn't seem to do that. – slugolicious Dec 16 '22 at 23:38
  • @slugolicious They don't claim to fix everything, no. They're much more honest than the large company grifters. – Sean Dec 17 '22 at 00:27

1 Answers1

1

It is the default behaviour of webkit-filter applied to the body element as described Here. The best solution would be to apply webkit filter to page elements and not to the body which contains the popup.

A quick fix would be applying top property with the popup height and bottom padding subtracted on the popup wrapper though results across different devices may vary.

#pojo-a11y-toolbar.pojo-a11y-toolbar-left {
    bottom: 20px !important;
    top: calc(100vh - 328px);
}
MrJgaspa
  • 86
  • 5