Content - Resizing text stops create content functionality

[nul800sebastiaan]

Steps to replicate:

1. Navigate to create content section
2. Resize text to 200%
3. Content tree and functionality is no longer present

Issue: Resize text: Users must be able to resize text, without using assistive technology, up to 200% with no loss of content or functionality

No longer have access to the content tree and be able to create content

Why it matters: Most people find it easier to read text when it is sufficiently large. People with mild visual disabilities, low vision, or limited colour perception are likely to find text unreadable when text is too small.

People with presbyopia also struggle to read small or low-contrast text. A 2018 study found that 1.8 billion people worldwide have presbyopia. (All people are affected by presbyopia to some degree as they age.)

How to fix: Make sure the text is scalable, and Make sure the container

• Good: Provides a scrollbar as needed, or
• Better: Is large enough to display all text at 200%, or
• Best: Scales to display the enlarged text without scrolling

W3 reference: https://www.w3.org/WAI/WCAG21/Understanding/resize-text.html

[MMasey]

@DannyLancaster when replicating this issue using standard browser zoom, the backoffice essentially goes into mobile view mode. Whilst the content tree is hidden, it can still be accessed by clicking on the Content section navigation item. (example gif below). Could this be more of an education thing rather than a code bug?

It's might be worth a separate ticket, (if it doesn't already exist), but it looks like most of the font sizing for the backoffice is handled using px values which is most likely a result of the legacy code. Ideally it should be using more modern font size value types such as em and rem . It may require quite a significant update to move all font sizes away from using px though, maybe better suited for the backoffice rebuild work.

[tiffy74]

Heya!

Huge thanks Mike for looking at this and a big #h5yr. Think it's a really interesting area because it throws up a number of conceptual issues (for me anyway) with regards to how we should approach accessibility.

Yes I discovered the same issue with absolute pixel values in the global styles when dealing with headings and line spacing. It's an issue that needs to be on their radar. I posted some comments in the RFC for the new back office about adopting a methodology for writing the styles that adopts some basic principles in order to support accessible design.

As for text resizing.. you may be right but actually this area has some real issues that there is lack of clarity with regards to wcag guidance and requires some further thought.

For example, the text resizing triggers the back office to render in mobile view, thereby the position and visibility of items change, which means a new layout that also needs to be tested. Plus, is there any functionality lost by switching to mobile layout? My bet is that there will be.. but can't say for sure.

One of the ways I can think of possibly dealing with this is to reference device rather than screensize in the media queries so that zooming on desktop won't trigger a mobile layout.

Have no idea of this is viable as it's just an idea and to be honest, I can't say how much of a problem that triggering mobile view by resizing text causes for accessibility.

My worry would be about what users would expect to happen.. so resizing text triggers mobile view which then makes the content tree disappear.. If the user wasn't expecting this behaviour, it requires them to then figure out how to un-hide the content tree. Which is perhaps an education issue.. but I can't be sure if that's the right position to adopt when it comes to accessibility.

[tiffy74]

@DannyLancaster @MMasey So what should we do here you think?