The slight problem (one of many) of 1.4.10 is that it was set out with high zoom on desktop in mind, and "lucked out" on justifying a classic mobile viewport width. So to me, most well designed native apps are going to pass this automatically, no? It talks about an ability to show content at a mobile size with the need to scroll horizontally. Maybe I'm missing something but there is nothing in 1.4.10 that talks about a requirement to magnify. Access Board has no plans for updating the 508 regulation to reference 2.1.
WCAG REFLOW SOFTWARE
Non-Web software shall not be required to conform to the following four Success Criteria in WCAG 2.0: 2.4.1 Bypass Blocks 2.4.5 Multiple Ways 3.2.3 Consistent Navigation and 3.2.4 Consistent Identification.Īnd before anyone asks: The U.S. Access Board handled certain SC when it came to native mobile apps and traditional desktop software: But who might we, the AG WG, ask to put it into writing that 1.4.10 is not applicable to native mobile apps?Īs a reminder, here is how the U.S. It is old meme: Your lack of planning does not constitute my emergency. I agree there is a problem, since I agree that the need for this sort of clarification is significant and time-sensitive - because EN 301 549 adopted WCAG 2.1 without addressing if any of the new SC needed particular attention when applied to non-web software. I hate to say it, but I do not think there can be quote official unquote discussion until such time that the AG WG formally starts working on updating WCAG2ICT. Which is kind of the point of this issue, and hence the title and request for official discussion.
The AG WG does not currently have written guidance on 1.4.10 should be applied to non-web software. I prefer 's note in his WCAG2ICT draft update: "It is likely that for software there will be more frequent cases where two-dimensional layout are required for usage or meaning."Įxamples of word wrap in native mobile apps: I agree it's somewhat more challenging compared with web, but the harder challenges come from app designs that didn't consider text enlargement, not from technical limitations of the platforms.
WCAG REFLOW ANDROID
Android and iOS do give developers robust tools for word wrap in native apps (links below). I would not categorically exempt mobile apps from reflow requirements. Without OS support for a reflow mechanism, an app-author would have to build different layouts manually, which goes beyond the intended scope of the reflow SC. Mechanisms for text enlargement include browser zoom, OS font size preferences (as correctly noted for mobile native apps), or user preferences within the web site or software product (example: Change font size in Mail on wrote: To make this statement more technology agnostic, we should instead say ".allow reflow when the user enlarges text". I agree with this statement when talking about desktop browsers, where browser zoom has become the best mechanism for resizing text without assistive technology. The spirit of 1.4.10 is that it allows reflow when the user zooms.
0 kommentar(er)
