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. 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. 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. Therefore this guideline does not apply to interfaces which provide toolbars.The spirit of 1.4.10 is that it allows reflow when the user zooms. Depending on the number of toolbar buttons, the toolbar may need to scroll in the direction of text (e.g., horizontally in a vertically scrolling page). Interfaces which provide toolbars to edit content need to show both the content and the toolbar in the viewport.Therefore this guideline does not apply to data tables. This relationship is essential to convey the content. Complex data tables have a two-dimensional relationship between the headings and data cells.Cutting up an image and stacking the blocks would render the content unusable so this is an exception in many cases. Graphics and video are by their nature two-dimensional.Exceptions:Ĭontent which requires two-dimensional layout for usage or meaning cannot reflow without losing meaning, and is therefore out of scope of this guideline. The width of 320 CSS pixels exactly corresponds to a desktop browser window set to a width of 1280px and zoomed in to 400%. This value lines up with the reported viewport width of small displays of many common mobile devices. The value of 320 CSS pixels was chosen as a reasonable minimum viewport width that content authors can achieve. For example, zooming into a vertically scrolling page should not cause content to be hidden to one side. It is also important that content is not hidden off-screen. Tracking is following along lines of text, including getting from the end of one line to the beginning of the next line.Īvoiding the need to scroll in the direction of reading in order to reveal lines that are cut off by the viewport is important, because such scrolling significantly increases the effort required to read. Enlargement enables perception of characters and the reflow of content enables tracking. People with low vision often need to enlarge text in order to easily read content. Content can be presented without loss of information or function, and without requiring scrolling in two directions.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |