E-mail List Archives
Thread: WCAG SC 2.5.8 (Target Size) in relation to zoomable content
Number of posts in this thread: 5 (In chronological order)
From: Steve Green
Date: Thu, Nov 14 2024 5:02AM
Subject: WCAG SC 2.5.8 (Target Size) in relation to zoomable content
No previous message | Next message →
The Understanding page for SC 2.5.8 (Target Size) says "The requirement is independent of the zoom factor of the page; when users zoom in, the CSS pixel size of elements does not change. This means that authors cannot meet it by claiming that the target will have enough spacing or sufficient size if the user zooms into the page."
That's fine, but what about content (a map in my current project) that has its own zoom controls? When the page loads, some of the clickable areas are very small and a 24px circle centred on them would overlap other targets. But this is no longer the case if the map is zoomed in.
It seems harsh to report a non-conformance, but I wouldn't want to recommend loading the map zoomed in because some of it would not be visible. Also, the CSS pixel size does change when using the map controls to zoom. I welcome your thoughts.
Regards,
Steve Green
Managing Director
Test Partners Ltd
020 3002 4176 (direct)
0800 612 2780 (switchboard)
07957 246 276 (mobile)
020 7692 5517 (fax)
Skype: testpartners
= EMAIL ADDRESS REMOVED =
www.testpartners.co.uk
Connect to me on LinkedIn - http://uk.linkedin.com/in/stevegreen2
From: Nicholas Bromley
Date: Thu, Nov 14 2024 6:08AM
Subject: Re: WCAG SC 2.5.8 (Target Size) in relation to zoomable content
← Previous message | Next message →
Would your map example not come under an Essential exception because - I assume - the size of the clickable area is directly linked to the size of a specific region of the map? The understanding page for 2.5.8 specifically mentions the pins on digital maps as one such exemption.
From: Steve Green
Date: Thu, Nov 14 2024 7:59AM
Subject: Re: WCAG SC 2.5.8 (Target Size) in relation to zoomablecontent
← Previous message | Next message →
Thanks, Nick - I hadn't noticed that. The example doesn't address the fact that it should always be possible to display a map at a zoom level that results in sufficient spacing. That might mean that the whole map area is not visible, but the provision of pan controls would deal with that.
The exception should only apply if it is essential that the map is displayed at a zoom level that results in overlapping targets because the whole of that area must be visible at the same time. I think I'm starting to see how this might work.
Scenario 1: It is essential that the map is displayed at a zoom level that results in overlapping targets. The exception applies regardless of whether or not the map has a built-in zoom feature.
Scenario 2: It is not essential that the map is displayed at a zoom level that results in overlapping targets. The map's built-in zoom feature allows it to be zoomed to a level where the targets can contain a 24 by 24 pixel square, and there is no loss of information or functionality. The success criterion is met. The exception is not required.
Scenario 3: It is not essential that the map is displayed at a zoom level that results in overlapping targets. The map either doesn't have a built-in zoom feature or it cannot be zoomed to a level where the targets can contain a 24 by 24 pixel square without loss of information or functionality. The success criterion is not met. The exception does not apply.
Steve
From: Nicholas Bromley
Date: Thu, Nov 14 2024 9:13AM
Subject: Re: WCAG SC 2.5.8 (Target Size) in relation tozoomablecontent
← Previous message | Next message →
Yes, those scenarios make sense.
In scenario 1, would you nevertheless recommend to clients they consider implementing zoom controls as a usability gain despite the exception being true?
Cheers,
Nick
From: Steve Green
Date: Thu, Nov 14 2024 9:27AM
Subject: Re: WCAG SC 2.5.8 (Target Size) in relationtozoomablecontent
← Previous message | No next message
Yes. I often make such recommendations although I'm careful to make it clear they are not mandatory.
Steve