Terminology "mobile" #851
Replies: 5 comments 2 replies
|
One aspect that I mentioned in discussions (on mailing list/slack) is that there's a difference in terms of user needs and implementation. User needs are generally device/environment agnostic - regardless of what the user is using ("desktop", "laptop", "smartwatch", "mobile" etc) the user need will be the same (e.g. having sufficient contrast, needing to be able to operate things with a keyboard, needing to have captions for videos with audio/spoken content, etc). So for requirements/guidelines/checkpoints ... the question about terminology or specific devices/environments is, in my view, not relevant. But undoubtably, when it then comes to satisfying those user needs, it does matter. And in those cases, it's often still more accurate in my mind to talk about a the specific aspect that a particular solution addresses or relies on (e.g. how to ensure things work with a keyboard in a native application on iOS/iPadOS; or making sure content adapts to a small viewport for web content inside a browser). Those would then be implementation techniques, and yes they will vary significantly. But in my mind the guidelines should cover the tech-agnostic user needs at the first level. So I wouldn't say we want "mobile-specific accessibility requirements" or similar, but rather general tech-agnostic requirements, which then have specific aspects that may well be more granular and specific to different environments/platforms/devices/situations, at an implementation/technique level. And there, it's still worth being specific, rather than just handwaving things into an amorphous "mobile" bucket. is a specific implementation/approach to satisfy a high-level tech-agnostic requirement specific to small viewports in browser-based content? small viewport in native iOS? native Android? is a technique for touchscreen interactions, regardless of what the underlying software environment, or size of the viewport/screen, etc is? then it's not a "mobile" implementation per se, but a "do this for touchscreen content" solution. Sure, you may still be able to mention "mobile", "desktop", "kiosk", etc, explaining that they are shorthands for devices/environments with certain characteristics. But even for implementations, in my mind it would be better to be specific to the aspect/characteristic that that particular implementation applies to when trying to satisfy the high-level tech-agnostic requirement. |
|
One aspect that I have emphasized before is that as an organisation carrying out audits of mobile apps of European (mostly German) customers, we are bound to refer to the EN 301 549 standard, which means its clause 11 Software and in addition whatever requirements from other clauses referenced (in a separate table of the standard) as applicable for software. Having the separate non-normative WCAG2Mobile document is therefore mostly useful in order to spell out aspects that may only be implicitly covered in WCAG - for example, when mobile apps define actions on elements that are available programmatically, in what way need these actions be equally available to other users not using AT? Having divergent recommendations, however (e.g. for target size) is problematic, and I think the line MATF has been taking now is to stick with WCAG as minimum and emphasize deviations (like a larger target size) clearly as recommended/best practice. But there may not be total agreement on this approach within MATF - we will see. So for that reason alone (that there may be things specific to native mobile apps that deserve specific recommendations or testing approaches) the term "mobile" (narrowed down to native mobile apps) is useful. That MATF also (per its charter?) covers mobile web is not useful and, I believe, should be avoided/corrected. |
|
I would appreciate it if someone could help clarify the following points. WCAG 3 aims to be technology-agnostic, but in the Explainer > Goals > Out of scope it says that “non-web technologies” are out of scope, as well as “software in the web technology stack”. What exactly is meant by those two terms? Related to that, where is “web” defined in the context of WCAG 3? I was looking for a definition but could not find one. What do we actually mean when we say that something is “web”? And finally, I am trying to understand the general nature of this discussion about “mobile”. In the current draft, the word “mobile” appears only five times: three times as “mobile devices”, once as “mobile application”, and once as “technologies such as mobile”. Is the discussion mainly about whether and how these references should remain, or is it about the broader scope and terminology of WCAG 3? I am asking because, when I read the current draft, it is full of web-specific concepts such as “web content” and “user agent” that do not exist in native mobile apps. At the same time, concepts that are relevant to native mobile apps, such as the accessibility interface alongside the keyboard interface, are not currently reflected. To me, this seems like a broader question than the use of the term “mobile” itself. |
|
agree ... i've poked at the use/definition of "web" in the past, and how it's become very fluid and often bent out of shape to try and make other things fit into it (like PDF ... sure, a PDF "can" live on the "web", but so can any other type of file). i'm guessing that "web" (or the pretense of "web") needs to remain since that's the remit of the world wide WEB consortium ... but this just leads to awkward things like this. |
It's a tricky balance, WCAG 2 is being applied to non-web contexts, so we're trying to make WCAG 3 applicable to non-web, but not going out of our way to include things specific to non-web contexts. It's an argument inside W3C as well.
I think it's the same as WCAG 2. It's not really defined as a term, but the units of conformance (page in WCAG 2) are the relevant definitions.
It's a term we keep using internally, and it creeps into the document (as you noted), so we're trying to settle it so we have a standard way of referring to... the thing we mean.
Quite a few of those are operating system / user-agent, but it's a good point, we should do a review to make sure it (especially the input provisions) are more tech-neutral. |
|
Following up on Gregg’s email about dropping the word "mobile," here is an idea that gives us technical accuracy while keeping things practical for developers and auditors. When we say "mobile," we are usually trying to address distinct technical and physical factors at once:
Lumping these under "mobile" doesn't match modern hardware, where touchscreens exist on desktop computers, small screens run desktop operating systems, and native software runs across every device class. While WCAG 3 covers basic pointer rules from WCAG 2.2, it still lacks guidance for native platform features, such as device accessibility settings, system text scaling, touch screen readers, and software responses to hardware sensors. Moving toward guidelines based on specific features allows us to fill these gaps while keeping high-level user needs tech-agnostic. At the same time, the concerns raised about losing "mobile" entirely are very real:
To bridge this gap without keeping a vague official "mobile" category, we could adopt a few key mitigations:
This approach could give us a future-proof set of guidelines while keeping things clear and easy to use for native app developers and auditors. |
|
I very much agree with, most of all, the concerns bullets in @lauracarlson's comment above and most especially the default-to-desktop issues. I have written on much of this already, so have cut down from one of my books to include only the most-relevant bits to support my arguments for the concepts of:
Yes, if anything, I am the voice in the wilderness saying to start deprecating desktop-oriented standards and prioritizing mobile as the default, but there are differences in use and design/implementation paradigms for web vs apps, for portable vs desktop, etc. so any one size fits all set of standards is hugely risky. Please don't be scared off by this cut-down thing being 20 spreads; because of how it's laid out it has lots of illustrations, a few chapter interstitials, some previous pages you can ignore and so on etc. Note the original document page numbers to guide when there’s a jump. You should be able to skim it in a few minutes to get the gist, then just refer back if you need to borrow any of it later. |
Uh oh!
There was an error while loading. Please reload this page.
AG began discussing challenges with the term "mobile" on an email thread. Some key points from that discussion are below:
Mobile is a commonly used term.
The reason mobile is not helpful is that it does not convey anything concrete. If mobile includes phones and tablets and tablets run windows — what is different about mobile in terms of what an author needs to do - from what they need to do for a desktop running windows with a touchscreen.
Terms that do have meaning:
these all present specific problems and can cause an author to have to do things differently to provide wide range access but Mobile - is not defined. Everyone has a different definition.
difference in how we address accessibility. The device-based line is
blurring, yes - but the technology-based line is not....So I’d suggest that the terminology should be more specific - “mobile app”, “web app” - rather than “mobile” as a device category.
The mobile taskforce is considering this question over the next few weeks and will present thoughts back to the AG on September 22nd. If you have additional points you'd like either group to consider, please add them here.
All reactions