- From: Mark Magennis <Mark.Magennis@skillsoft.com>
- Date: Fri, 20 Mar 2026 13:36:03 +0000
- To: "Tumelaire, Justin" <Justin.Tumelaire@cengage.com>, "w3c-wai-ig@w3.org" <w3c-wai-ig@w3.org>
- Message-ID: <CH4PR08MB10540CD8D88335E5381CA19B5E54CA@CH4PR08MB10540.namprd08.prod.outlook.co>
Hi Justin, You're not just viewing in a 320px wide viewport, you're using a device emulator. Although it's possible to test this way, I wouldn't recommend it because the device type may be wrong, the view will be very small and unrepresentatively tall, and the vertical scrollbar may be misleadingly wide. I can't see what device type you have selected because the device type menu isn't showing. You will need to choose "Add device type" from the options menu (three dots icon) in the responsive design viewer. It should be set to Desktop, not Mobile because if the website’s media queries use device type rather than viewport width, the result may be fine in the emulator but not when zoomed on desktop. The fact that the device emulator shows a lot more vertical content than zooming to 400% is also an issue, although this wouldn't affect WCAG 1.4.10 compliance. The issue is that realistically, someone who has a 1280px wide screen also has a 720px high screen. Zooming to 400% not only reduces the width the 320px but also reduces the height to 180px. This is what will happen in reality, so although WCAG 1.4.10 doesn't require vertically scrolling content to be visible and usable at 180 virtual pixels high, users certainly do. At this height, if you have a fixed header and footer with scrolling content in between, which many web pages and modal dialogs do, then the available height may not be enough to fit any of the scrolling content, so nothing can be seen or used at all. You should look out for this and, unless you're only interested in WCAG compliance, report it as a serious accessibility fail. The scrollbar issue arises because for some users the browser's vertical scrollbar may obscure some of the content. Windows by default uses traditional scrollbars which are always visible on screen and take up aprox 16px of the available viewport width. MacOS by default uses overlay scrollbars which disappear when not being used so the whole viewport width is visible except when scrolling. In Windows having the scrollbar visible is part of the user experience for most users, so if any content is obscured by the scrollbar this is a real accessibility issue. If a page is tested using the device emulator with the device type set to Desktop the scrollbar is visible in Windows and takes up 16px of the 320 pixels which is a significant amount. But if the page is tested at 1280px and 400% zoom the scrollbar takes up only 4 virtual pixels which is probably negligible. So it is best to test at 1280px and 400% zoom. Remember that the purpose of WCAG 1.4.10 isn't to support people viewing on mobile screens 320px wide but to support desktop/laptop users zooming up to 400% on a1280px screen. Mark ________________________________ From: Tumelaire, Justin <Justin.Tumelaire@cengage.com> Sent: Thursday, March 19, 2026 18:15 To: Patrick H. Lauke <redux@splintered.co.uk>; w3c-wai-ig@w3.org <w3c-wai-ig@w3.org> Subject: [EXTERNAL] RE: Difference in 1.4.10 Testing Approach You don't often get email from justin.tumelaire@cengage.com. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> Thank you, Patrick. I’m not sure if attachments come through but I will attempt them. Here is the description: 1. In an eReader experience, when set at 1280px and zooming to 400% the reading pane containing the book content is almost entirely obscured by the navigation and menu options that are reflowed to the bottom of the screen because these components scale up with the zoom. 2. When setting the viewport to 320px without zooming, the reading pane containing the book remains entirely visible. The navigation and menu options resize proportionally to the viewport. I appreciate it! Justin From: Patrick H. Lauke <redux@splintered.co.uk> Sent: Thursday, March 19, 2026 1:57 PM To: w3c-wai-ig@w3.org Subject: Re: Difference in 1.4.10 Testing Approach Functionally, both approaches are supposed to lead to the same end result (viewport width of 320 CSS px). What differences are you seeing? On 19/03/2026 17: 38, Tumelaire, Justin wrote: > I hope all is well. I’m finding that different groups Functionally, both approaches are supposed to lead to the same end result (viewport width of 320 CSS px). What differences are you seeing? On 19/03/2026 17:38, Tumelaire, Justin wrote: > I hope all is well. I’m finding that different groups test 1.4.10 Reflow > using different methods: > > 1. Set width to 1280 px (for vertically scrolling content), zoom to > 400% and test > 2. Change the viewport to 320px without adjusting zoom and test > > In my experience, the results are different. What may create issues with > a loss of content using option 1 are not issues when testing using > option 2. Are both options acceptable for testing reflow? Does option 1 > catch a larger subset of potential issues? > > Thank you! > > Justin > -- Patrick H. Lauke * https://urldefense.com/v3/__https://www.splintered.co.uk/__;!!MXVguWEtGgZw!J3RjtczJdnjZl9huKs5kSmXwCdabVUALpnx-s5ARGC35546HhDPjVbOILVlJ1nCCnZb0KmFjyaCNcUrkl1i5dISJ$<https://urldefense.com/v3/__https:/www.splintered.co.uk/__;!!MXVguWEtGgZw!J3RjtczJdnjZl9huKs5kSmXwCdabVUALpnx-s5ARGC35546HhDPjVbOILVlJ1nCCnZb0KmFjyaCNcUrkl1i5dISJ$> * https://urldefense.com/v3/__https://github.com/patrickhlauke__;!!MXVguWEtGgZw!J3RjtczJdnjZl9huKs5kSmXwCdabVUALpnx-s5ARGC35546HhDPjVbOILVlJ1nCCnZb0KmFjyaCNcUrklx7rcmLt$<https://urldefense.com/v3/__https:/github.com/patrickhlauke__;!!MXVguWEtGgZw!J3RjtczJdnjZl9huKs5kSmXwCdabVUALpnx-s5ARGC35546HhDPjVbOILVlJ1nCCnZb0KmFjyaCNcUrklx7rcmLt$> * https://urldefense.com/v3/__https://flickr.com/photos/redux/__;!!MXVguWEtGgZw!J3RjtczJdnjZl9huKs5kSmXwCdabVUALpnx-s5ARGC35546HhDPjVbOILVlJ1nCCnZb0KmFjyaCNcUrkl5ZBr6bd$<https://urldefense.com/v3/__https:/flickr.com/photos/redux/__;!!MXVguWEtGgZw!J3RjtczJdnjZl9huKs5kSmXwCdabVUALpnx-s5ARGC35546HhDPjVbOILVlJ1nCCnZb0KmFjyaCNcUrkl5ZBr6bd$> * https://urldefense.com/v3/__https://mastodon.social/@patrick_h_lauke__;!!MXVguWEtGgZw!J3RjtczJdnjZl9huKs5kSmXwCdabVUALpnx-s5ARGC35546HhDPjVbOILVlJ1nCCnZb0KmFjyaCNcUrklzqhQY7d$<https://urldefense.com/v3/__https:/mastodon.social/@patrick_h_lauke__;!!MXVguWEtGgZw!J3RjtczJdnjZl9huKs5kSmXwCdabVUALpnx-s5ARGC35546HhDPjVbOILVlJ1nCCnZb0KmFjyaCNcUrklzqhQY7d$>
Received on Friday, 20 March 2026 13:36:13 UTC