– DRAFT –
MATF 23 April 2025

1.4.10 Reflow

JJ: Recapped previous discussion and conversations about the ability to set a mobile device's dimensions to the normative requirements stated in the SC.

<Jon_Gibbins> Sorry I’m late to the call

<pauljadam> You can check your screen width with this app on the Horizontal Scrolling technique page https://apps.apple.com/app/accessibility-techniques/id6474141089

<pauljadam> Horizontal Scroll View technique shows your width

JJ: Is it acceptable to use the techniques in Mitchell Evan's comment, even if they don't get exactly to the WCAG dimensions?

JJ: Related question from last week -- Orientation: Does content behavior at landscape also fall into this SC?

JJ: Recapping question from Detlev in issue #25 - with a device in landscape orientation, it may not be possible to get a device to the specified dimensions; how do we deal with content lost in that case?

<pauljadam> I think you can get 320 with Display Zoom on iPhone SE, iPhone, or iPhone Pro

<JJ> https://github.com/w3c/wcag2ict/discussions/101#discussioncomment-5233702

julianmka: There's so much fragmentation in Android hardware, its especially important to have people test at 320px.

Joe_Humbert: Devices also have 1 or more, or foldable screens. Can those larger screens be set to the smaller resolution?

Joe_Humbert: Android tablets use the same OS as Android phones, there's no separate OS like iPadOS

<pauljadam> Split views and other ways to show skinny apps on iPad is something I've not really looked at yet

julianmka: I have a Samsung Z-flip 6 and even without tweaked display settings, I notice apps don't always lay out or display well on the narrower screen.

<Jon_Gibbins> Thinking through my fingers here… I do wonder if the 320 CSS pixels requirement is a threshold that doesn’t map to mobile. It was chosen because it’s the equivalent width of 1280 px wide at 400% zoom in web browsers. Perhaps we should take a “typical” mobile width and calculate the equivalent pt/dp widths of the largest zoom / text size setting for the platform.

<Jon_Gibbins> That said, we don’t have the power to change WCAG thresholds. But perhaps worthy of a note.

JJ: Tools like whatismyscreenresolution.net show dimensions in CSS pixels, but is that a direct mapping to the device? Is 320x694 CSS pixels the same as 320x694 dp or pt?

<pauljadam> yes I can check my iPhone resolution on a website and it says 320

JJ: We can at least add a note emphasizing the units and share directions on how to adjust the screen dimensions on Android and iOS

<pauljadam> it's weird that on iPad Split Views those web resolution checkers are not working, it always says the same width

<Jon_Gibbins> JJ: Agreed on note. And particularly on mapping CSS pixels for mobile app designers / devs. Understanding what CSS pixels means on iOS/Android is the most common question I get on this topic.

<pauljadam> height is irrelevant

Joe_Humbert: 1.4.10 doesn't only require the 320px width, but also a 256px height. I can't get an iphone to 256 px high.

<Carolina> i don't think both apply at the same time

JJ: The width and height requirements don't necesarily have to be at the same time.

<Carolina> 320 when we are scrolling vertically and 256 if we are scrolling horizontally

<pauljadam> WCAG says 320 so we can't pick a different number

Jamie: We could aim for the smallest phone size available today/

<pauljadam> Using the Display Zoom setting is basically picking the smallest phone available

<pauljadam> WCAG does not say "as close as possible" it says 320

<Joe_Humbert> is there a way to get an iPhone to the 256 px height? Is that only in Landscape?

<JJ> https://www.w3.org/WAI/WCAG22/Understanding/reflow.html#why-specifically-320px-and-256px?

Jamie: The Understanding document refer to the desktop dimensions as a starting point for a website on a desktop computer. They were chosen for ease of testing. Could this section be updated to acknowledge mobile devices in today's world?

<pauljadam> My only worry would that if Apple changes their Display Zoom resolution from 320 width to 321 then this becomes irrelevant

<Jamie> Thanks julianmka for the summary version

JJ: Our TF can't change the numbers in Undrstanding or the SC, but we could raise the matter with the larger group.

<pauljadam> no I don't think it's possible to get an iPhone into 256 height

<pauljadam> tried it

JJ: Auditors have to use their judgement already, maybe they just add a note to their report if they are unable to get their device to 320 wide and 256 high.

Joe_Humbert: I just tried putting my device in landscape mode and it says the height is 320, using the Display Zoom setting.
… Using an iPhone 15

JJ: Maybe an iPhone SE would have a different result.

<JJ> Using https://apps.apple.com/app/accessibility-techniques/id6474141089 to measure size

<JJ> Or CSS Pixels: http://whatismyscreenresolution.net/

Jamie: I have an iPhone 12 mini and often see content that is clipped or otherwise displayed wrong. I feel that a big part of addressing this SC includes responsive design for mobile, with layouts that adapt to different screen sizes.

JJ: So one note about how to set your display size smaller. And then a second note that there are many different screen sizes to consider, and that apps should at least work on the smallest screen if not be perfectly pretty.

ACTION: Work out note for setting display size on Android / iOS to be 320 width / 256 height

ACTION: Work out note for best-practices 1.4.10 on mobile devices / mobile applications

pauljadam: I've written a test case to teach testers how to test for reflow with an iPhone, set with Display Zoom, and looking for content that requires horizontal scrolling. My thought is that at 320 or smaller, there should be no horizontal scrolling views, larger than that there can be.

julianmka: Do we need to consider non-Android/iOS OSes at this time?

<Carolina> wouldn't this depend on the resolution of each device as well?

<Carolina> the pixel density is different perdevice

JJ: We should be clear when we're only considering Android and iOS. It would be nice to get beyond those, though.

<JJ> yes pixel density needs to be considered, assuming most mobile devices have a browser, they could access a website that shows resolution in CSS Pixels

<JJ> Question: is reported resolution in CSS Pixels equal to DP (Android) and PT (iOS)?

<pauljadam> 320 width is all that matters, can be a tablet in split views or a phone

Joe_Humbert: It would be difficult to get other OSes' information on adjusting screen size, for instance. UbuntuTouch doesn't come preinstalled on many devices. What about tablet-only OSes like FireOS?

1.4.13 Content on Hover or Focus

JJ: Lots of those other OSes are based on Android, so they might work similarly.

JJ: Summarizing 1.4.13 and highlighting some previous questions about mouse usage and iOS mirroring on the latest version of MacOS.

<JJ> w3c/matf#6 (comment)

JJ: Megan_Pletzer reported testing on mobile web tool tips with the mouse (comment in Issue above)

<pauljadam> I don't see any hover styles using a mouse in iPhone mirroring or using a mouse on iPad

JJ: Assigning the issue to Megan_Pletzer and Jamie to work together on research for this SC.

<pauljadam> actually I'm wrong I do see some hover styles on header buttons on iPad with a mouse

JJ: Once we get through the tasks listed in the issue, and define "tooltip," we should be good to go.

<pauljadam> In SwiftUI, tooltips are available on macOS, but not yet natively supported on iOS or iPadOS as of 2025.

Joe_Humbert: A lot of conversation on hover, but what about behaviors on focus events?

JJ: Which types of focus? The SC talks about keyboard focus.
… If the SC says "keyboard" and not "keyboard interface," we just consider keyboard.

<pauljadam> I would keep the scope to keyboard and pointer hover only to match with the WCAG success criterion wording.

pauljadam: With this SC, you're just testing for tooltips covering things when you hover or set keyboard focus on it, and then checking that the escape key or some other way exists to hide it.