Comments (21)
yeah, i think this sort of clarification needs to be much more prominently made even for web content, and then when we finally get around to the mythical "how it applies to other ICT" document
from wcag2ict.
It is worth noting that 1.4.10 Reflow has been included as the success criteria in EN 301549, clause 11 Software, which is the likely benchmark for mobile app testing at least across Europe (including the latest draft, V3.1.1, which now also includes 4.1.3 Status messages).
I also noted in recent app testing that apps may offer reflow (of sorts) on a tablet breakpoint in that the landscape view might be different from the portrait view, but not on a smartphone.
My general line would be that due the different enlargement mechanism in mobile apps (OS level zoom, OS level text size settings), the Reflow criterion does not generally apply on mobile devices (while it is commendable to offer it where possible). It should therefore, I think, be dropped in EN 301549 clause 11, or its application be qualified in some way.
from wcag2ict.
beyond native "mobile" apps, i'd start questioning further how some of the SCs like 1.4.10 apply to native desktop/laptop apps - e.g. are we really expecting applications (like Word, Photoshop, etc) to satisfy the requirement of working fully and completely in a reduced desktop size of 320x256 ? that sort of level of adaptation is not present in the vast majority of native software applications today.
from wcag2ict.
This issue also overlaps with #4
I have opined elsewhere that it was cavalier for EN 301549 to apply 2.2 to non-web ICT before the WG got around to revisiting WCAG2ICT.
from wcag2ict.
The AG WG does not currently have written guidance on 1.4.10 should be applied to non-web software. Which is kind of the point of this issue, and hence the title and request for official discussion
.
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. 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.
It is old meme: Your lack of planning does not constitute my emergency. But who might we, the AG WG, ask to put it into writing that 1.4.10 is not applicable to native mobile apps?
As a reminder, here is how the U.S. Access Board handled certain SC when it came to native mobile apps and traditional desktop 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.
And before anyone asks: The U.S. Access Board has no plans for updating the 508 regulation to reference 2.1. (or 2.2, or 3.0).
from wcag2ict.
The spirit of 1.4.10 is that it allows reflow when the user zooms. Native apps generally don't zoom as such (though their text/layout may rearrange/reflow based on the mobile OS's - or the app's - text size/scaling settings). As such, I'd argue that this doesn't necessarily apply to native apps on mobiles/tablets (though it could be made to apply to native apps on desktop OSs, where the app window can be resized).
Worth noting that the smaller viewport dimension (in CSS/logical pixels, rather than physical pixels) of most smartphones is around 320-380 pixels (the width, when in portrait / the height, when in landscape). For older smartphones where it is 320 pixels, arguably a native app passes the test if it only requires scrolling in one direction (if at all).
from wcag2ict.
Sounds like something worth discussing in the context of WCAG2ICT for WCAG 2.1. I started up a document here as a discussion point.
from wcag2ict.
from wcag2ict.
Hi @mraccess77,
The understanding doc does cover mobile browsers, but for native apps I don't think there is the same kind of mechanism.
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. In theory it could only work for devices with more than 320px to play with, e.g. allowing a tablet to show the phone-sized view.
I've created a "wcag2ict" label for this.
from wcag2ict.
@patrickhlauke wrote:
The spirit of 1.4.10 is that it allows reflow when the user zooms.
I agree with this statement when talking about desktop browsers, where browser zoom has become the best mechanism for resizing text without assistive technology. To make this statement more technology agnostic, we should instead say "...allow reflow when the user enlarges text". Mechanisms for text enlargement include browser zoom, OS font size preferences (as @patrickhlauke correctly noted for mobile native apps), or user preferences within the web site or software product (example: Change font size in Mail on Mac).
@alastc wrote:
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.
I would not categorically exempt mobile apps from reflow requirements. Android and iOS do give developers robust tools for word wrap in native apps (links below). 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. I prefer @DavidMacDonald '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."
Examples of word wrap in native mobile apps:
- https://developer.apple.com/documentation/uikit/uilabel
- https://developer.android.com/training/constraint-layout/
from wcag2ict.
Hi @mitchellevan,
We'd avoided the 'enlarges text' terminology because it led people to think it was about text-only resizing, and it was more about adjusting layout (due to the content-size changes) than just text sizing.
I agree that there are mechanisms for word-wrapping, but are they not covered by 1.4.4 already?
https://www.w3.org/TR/wcag2ict/#visual-audio-contrast-scale
Do the layout options that you pointed to allow for 200-400% changes in text sizing? If not, it does seem like an unrealistic requirment.
from wcag2ict.
In a separate github thread we discussed that this requirement only applies to blocks of content and not the window as a whole. That's how I read it and how it could be applied to software.
from wcag2ict.
I'm late to this discussion folks, but someone was referencing the issue asking if they don't have to consider Reflow on a mobile app.
Maybe I'm missing something but there is nothing in 1.4.10 that talks about a requirement to magnify. It talks about an ability to show content at a mobile size with the need to scroll horizontally. So to me, most well designed native apps are going to pass this automatically, no?
My recollection is that it was partially written the way it is to allow it to be mainly focused on desktop displays.
from wcag2ict.
@mbgower I think that’s generally how people test it today. However we’re often not certain if the mobile view is actually at 320 CSS pixels.
from wcag2ict.
Maybe I'm missing something but there is nothing in 1.4.10 that talks about a requirement to magnify. It talks about an ability to show content at a mobile size with the need to scroll horizontally. So to me, most well designed native apps are going to pass this automatically, no?
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. But originally this was indeed about magnifying to 400% or more. going back to the original intent, I don't think it's realistic to assume that even on a smartphone, users that require high magnification will expect to be able to change the viewport for native content on the fly, as that simply isn't possible (compared to zooming web content inside an otherwise fixed-size native browser, but then the other issue is that on mobile/tablet browsers don't do reflow per se either, with some exotic exceptions...so beyond essentially requiring mobile-friendly viewport to be set, there not much more even for web content on mobile/tablet that can be done from the author's point of view).
from wcag2ict.
urgh, apologies, i'm probably rehashing things i said before in this old discussion. ho hum.
from wcag2ict.
from wcag2ict.
Moved to WCAG2ICT repository as the new TF will work to address issues tagged as WCAG2ICT from the WCAG repository.
from wcag2ict.
WCAG2ICT TF discussion on application of 1.4.10 Reflow to non-web software and documents is happening in the WCAG2ICT Issue #98 where we are discussing and drafting guidance content. Join in there if you wish to weigh in. I know some of you already are.
from wcag2ict.
from wcag2ict.
The TF has published guidance for Applying 1.4.10 Reflow to non-web documents and software in its FPWD. If you have questions or comments on this guidance, please open a new issue.
from wcag2ict.
Related Issues (20)
- SC problematic for Closed functionality: SC 2.1.1 Keyboard HOT 2
- WCAG2ICT Task Force web page issues HOT 3
- Use of requires or required or requiring HOT 4
- Project task: Update contributors and company affiliations HOT 12
- Project task: Remove, update, or add editor's notes HOT 1
- Project task: Task force review of the draft and agreement to publish HOT 1
- Project task: Set up for AG WG review of latest editor's draft and newly added SC HOT 1
- Project task: Set up and track horizontal review of the draft HOT 4
- Project task: Create communication announcing publication and when comments are due HOT 2
- Project Task: Update the Status of this document and abstract HOT 7
- 4.1.1 Parsing is missing the WCAG 2.2 content in the built document HOT 1
- Remove "previous version" respec key HOT 3
- AG WG Review: 4.1.1 Parsing WCAG2ICT guidance HOT 4
- [Editorial] Take a pass for Oxford comma and decide whether or not to use HOT 3
- AG WG Review: 3.3.8 Accessible Authentication (Minimum) WCAG2ICT guidance HOT 3
- AG WG Review: 3.2.6 Consistent Help WCAG2ICT guidance
- AG WG Review: WCAG2ICT Guidance for Products with Closed Functionality HOT 4
- AG WG Review: WCAG2ICT editor's draft HOT 1
- Focus Not Obscured needs a note for non-web software HOT 4
- Feedback from Microsoft on wcag2ict Reflow notes 5 and 7 HOT 7
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from wcag2ict.