TOPIC:

Xerte activities fail WCAG 2.1 AA Success Criterion (1.4.10: Reflow) when zoomed at 400%. The header and footer obscures the body content. Please view attachment. Please advise if this can be corrected. Regards,

Hi Taou,
Thanks for the screenshot.
This is an issue that depends a lot on page choices. More complex pages with more elements will suffer more when zooming via the browser zoom. However, there are alternative approaches that can help. I'll illustrate the issue with some of my own examples:

A simple page (400zoomsimple.jpg below)

works well and it is appropriate that the header and footer magnifies - if they have poor sight they need to see the navigation controls clearly.

A more complex page (400zoomcomplex.jpg) is more problematic for reasons suggested above

BUT on this example it is still legible, and still workable since the text can be scrolled - but it's aesthetically clunky - however, there are alternative ways of getting magnification - read on...

Changing the default text size in the browser can provide an alternative way of reading the content. WCAG requires 200% text resize and this can be achieved either in the browser settings or using a browser plugin like A+Font size changer lite. The example below (200txtsize.jpg) is at normal browser zoom - 100% - but has had 200% text size increase. This works on the body text without significantly impacting on header and footer - it's about the same visual experience as 400% browser magnification - see image

The best option is often a combination - for example the file "Combined.jpg" below gives you 150% text size increase along with 200% browser zoom.

This gives the best of both worlds.

So I'd argue that it's not so much that Xerte "fails this zoom criterion" but that
1) choice of page type is a factor influencing the effectiveness of "zoomability". Pages with more complex elements clearly limited behaviour options when zoomed to 400% on a fixed size screen,
2) Users needing high magnification should be encouraged to increase browser font size, thus reducing the need for browser zoom - though this may make the navigation bar smaller than is comfortable for their level of sight.

Accessibility is often a compromise between different features and functionality with different benefits. We've tried to give as helpful advice as possible on the Xerte Toolkits accessibility statement - xot.xerte.org.uk/play.php?template_id=214#homesection3

Hope that helps - and of course, screen size and resolution can also play a part! Magnification is one of the trickiest bits to get right in interactive content but I think Xerte does as good a job as I have seen.

Alistair

Hi
the development team have been discussing what we could do to improve this, especially when the higher end of the zoom range is used. By default the text in XOT projects is responsive and on desktops and laptops larger than you might find by default from other tools. e.g. Zoom levels up to about 200% don't really cause this problem and that level of zoom is possibly sufficient.
I'm curious have you asked about this based on feedback from a user who needed high zoom levels or are you just testing against WCAG criteria?
Do you have a suggested solution?
We know that what contributes to this being an issue is the absolute positioning of the header and footer but that also brings accessibility benefits e.g. the navigation always available. On smaller mobile devices you may have noticed that the header is no longer positioned that way and so scrolls up with the content but at the moment the footer does remain fixed at the bottom - which again has benefits (as well as disadvantages when higher zoom levels are needed). Unfortunately this is also where there is never going to be a perfect solution for all page types e.g. we have a number of interactive pages which will never be practical at higher zoom levels on smaller mobile devices. Technically content should reflow but some of the interactions aren't likely to be viable even at 100%. Authors need to adopt a mobile first approach if that is a priority or provide the same content in an alternative format for smaller screens e.g. the Bootstrap template could be used for those requirements.

One of the options we've been discussing is to possibly provide an optional property to set the header and footer to be sticky rather than absolute. However this isn't a simple task and many of the page types take account of the current footer size and position. So this is on our list to discuss next time we have a developer day but if you need a solution short term then it would be useful to know if the OU could contribute in some way e.g. development resource and/or funding?

HTH
Ron