Rethink the term "mobile" #3
Comments
|
To give a "too long; didn't read" of my lengthy post: focus on features (motion sensor? touchscreen/pointers? typically small viewports?) rather than trying to pigeonhole characteristics into a single device type, as boundaries between device types have been increasingly blurred for ages and are simply outdated/inaccurate. |
|
I agree. It is now possible to play all mobile apps on a desktop computer and touchscreen desktop computers have all the characteristics of mobile devices. Also, the tablets are just overgrown smart phones, (or smart phones are miniaturized-and often not miniaturized - tablet computers that have all of the capabilities of what used to be desktop computers. Now with VR headsets, we could have large screen computing, which looks exactly like someone sitting at a desk, while walking down the street using gestures on their mobile glasses.We need to drop the word mobile and figure out what characteristics we thought that represented and start talking about them separately since they appear on both stationary and mobile devicesGreggLife is short and dictation is faster. Excuse errors. On Jul 21, 2023, at 7:00 AM, Patrick H. Lauke ***@***.***> wrote:
To give a "too long; didn't read" of my lengthy post: focus on features (motion sensor? touchscreen/pointers? typically small viewports?) rather than trying to pigeonhole characteristics into a single device type, as boundaries between device types have been increasingly blurred for ages and are simply outdated/inaccurate.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
rachaelbradley
added
the
Please Review
|
As the intent for WCAG3 is to base guidelines on user need, IMO "mobile" is not a user need in this context. User needs that are part of mobile UX would seem to include:
ThoughtsWith these examples, it should be clear that while important for mobile, these have use in other contexts—the values for some features such as zoom will undoubtedly need to be different—arguably zoom specifications should be aligned with available screen real-estate and resolution, rather than "zoom for mobile". So, if the items such as zoom, contrast, focus, are handled for mobile in each of the respective, related guidelines, then a separated "mobile" group is needed only for things such as "user is not prevented from requesting desktop version" or "not distracted when using the mobile device for navigation"... |
as I pointed out in my original post, yes |
|
My two cents: A desktop or laptop with a touch screen is a little like a mobile device, but is also different in many ways. And a smart phone with a full-size keyboard plugged in is a little like a laptop, but is also different. One big difference between mobile and desktop is context – the mobile phone is with you all the time and the laptop you have to sit down for. It’s not the same experience (even if you have a VR headset, which is a whole different subject…) because when you're walking down the street you’re moving. This makes for a different experience. Most of the growing number of people who use smart phones as their go-to devices don't have VR headsets and are dealing with small screens and platforms with different abilities than desktops and laptops. Development is different on mobile, to the extent that there are apples-to-oranges issues in WCAG for mobile developers. I agree that framing things around user needs is good. One key thing users need is to be able to choose what form of input and output to use at any given time, including mixed input and output. Making sure mobile is addressed well – however that happens – will help. It's not addressed well now. Dictation is faster? It can be. It depends how and where it’s used. It’s also different, and also still not well addressed in standards. Speech input includes dictation and also using speech to control the device. These are two different animals. Also here's a really good resource around mobile development: |
|
Kim ... in that case, boil down what the actual thing is that is different. don't use a generic term and say "mobile", trying to lump all sorts of different (and often blurry/fluid) devices into it. Focus on the underlying feature/user need.
i believe your distinction here is more "web application versus native application". the same applies just as well for development of native applications on laptops/desktops. (so nothing to do with "mobile" per se) And, to bring to a point: the fact that in WCAG 2.1 "Pointer Gestures" came from MATF, and (if using the same mapping of TFs) is lumped under "Mobile" in WCAG 3, is slightly nonsensical, since the SC applies to mouse on desktop/laptop just as well. Same with "Label in Name" ... originated in MATF, but hard pressed to work out why anybody would consider it a "mobile" only issue. That was my point in the original thread and here...the pigeonholing by device category (which is flawed these days anyway, as there's no clear delineation anymore of what is and isn't a "mobile" device, and many characteristics associated historically with "mobile", like touchscreens, are now present in all sorts of other devices outside of the classic "mobile" bucket) was never a good idea, and we should not carry it forward into WCAG 3 |
One thing that I believe is still limited to mobile devices is the ability to control the direction of scrolling. On laptops and desktops, one can either use the arrow keys or the scroll wheel to only scroll in one direction. By default on a mobile device, however, one must use their finger to physically move the content, which can make scrolling on pages with long tables or code samples particularly annoying. This means that it might be better to have tables and The reason I bring this up is because I think it's still useful to have an idea of mobile when writing the criteria. I'm all for publishing them without mentioning specific device types, but I worry that if we don't consider specific device types while writing the criteria, we might forget about some of the few remaining differences. This is more of something to think about going forwards than it is a specific issue with this proposal. |
that's not a trait of "mobile", that's a trait of "touchscreen input" ("direct manipulation input"). you can have "mobile" devices that also have an attached bluetooth mouse and/or keyboard, and conversely you can have "desktop"/"laptop" devices with a touchscreen. |
Yes, but it is a trait of mobile devices by default, because they do not have keyboards or mice attached by default. Conversely, Desktops and laptops do have at least a keyboard attached by default. My point wasn't that it's an actual trait of mobile, but instead that it's a trait that might be forgotten about if we don't occasionally think of mobile devices specifically. |
|
but that wouldn't be forgotten if the narrative is around users who use touch to interact with their device, regardless of whether it's a phone, tablet or a touch screen for a desktop. |
|
Hi @u9000-Nine
This is not an author-centric issue, and is more dependent on the OS/technology. iOS scrolls in only one direction, for instance, locking things in columns. And here again, this relates to screen size. For low vision, on a laptop or desktop, it is common to zoom the screen up so much that a standard screen is in fact the same effective resolution as a phone, causing the same column-locked behavior. This is why screen size related SCs need to be directly addressed as “screen size”, not mobile. This goes for other considerations of “mobile/desktop”. At the moment the only user agent determining factor is a media query for screen size, to determine if something is “mobile”. Because small effective screen size is used even in desktops by low vision, there should not be such a distinction in the language. One SC that would need the term “mobile” would be: SC for MOBILE:If a site has a mobile-only-app version and separate full desktop version, it is possible for the user to request the full desktop version. Extending this usefully indicates the need for additional media query and user agent preferences. |
here i'd be more specific about how a site decides to show the "mobile" version. user agent sniffing? silly heuristics (small screen + coarse pointer + no hover)? and then craft an SC along those more generic lines |
How do they determine what to show? Okay, so a responsive site just adjusts to screen size and doesn’t per se have a mobile version, I.ez it’s one unified version, so not part of the SC example I indicated. I am referring to sites with a completely different gestalt for mobile. How/when these sites determine is not so relevant IMO, in some cases as early as the load balancing reverse proxy, or triggering a redirect i.e. from www.example.com to m.example.com, which uses different CSS, different HTML, etc. It’s this later type I’m mentioning, and the “means” of determining if it’s redirected to the mobile device servers is not germane from the user perspective. The relevant factor for the user is “hey I’m getting the mobile version with the Fisher-Price simplified UI, I want the full desktop UI”. In this case, the user wants to be redirected to desktop, probably with persistence. It was the one example I could think of that could indicate use of the term “mobile”. But with the foregoing in mind, instead of mobile then how about the phrasing: SC for ALTERNATE LAYOUTSIf a site has a default, full-featured desktop version, and one or more alternates optimized for certain device types or screen sizes, then:
SCOPE: This does not apply to embedded systems, where a specific alternative layout is part of system security, or where page content is only available on the given alternative layout. |
|
it is germane because that makes the difference between writing a wooly SC a la "If a site has a mobile version and redirects a mobile user to it..." (since the term "mobile" is and will be a handwavy and inaccurate label to try and pigeonhole things), versus a more robust "If a site, based on factors including user agent name and capabilities, redirects users to a separate site, ..." which then will also apply to other situations, such as users accessing a site on a "TV" browser, or a "game console" browser, or any other situation where they're using a UA that for some reason gets identified as one that should be redirected to another version of the site, while the user really would want to go to the "regular" version. otherwise, you risk once again making a lovely SC for "mobile", which all of a sudden doesn't apply to other scenarios that are exactly the same but where the user is not on a "mobile" device, even though what the site is actually doing technically behind the scenes (taking cues from the UA string, etc) is exactly the same. and then we get to the "maybe our understanding document should explain that when we said 'mobile', what we actually meant was any sort of device/browser/environment detection..." |
|
I "think" we're in agreement Patrick, hence the revised example SC that does not mention "mobile" and instead says "...one or more alternates optimized for certain device types or screen sizes..." RE: "not germane to the user"What I was saying (that I think might have been lost in translation) is, from the user perspective they're not necessarily going to care if the site decided to provide an alternate based on screen size, or based on operating system, or based on user agent. The user is only concerned that:
This excursion came up with the thought experiment of "is there anything valid to use the term 'mobile' on", and my last post was stating that even if there is there are other ways to state it clearly, which I thought I did but maybe I didn't. |
Yes, but precise wording such as this would create a loophole where developers could simply identify the device type with some other method. It might be better to say something like the following:
I'm talking more about input-type--related SCs. In that case, there are several other media queries which can be used to approximate a scroll wheel or other inputs, such as I agree that we shouldn't think about device types when considering screen size because that is very poorly correlated with device types. The functionality of inputs, however, can very depending on device types. For example, my laptop has a touchscreen, but even when I unplug the external mouse the pointer is set to |
|
As an aside
note that this is a bug, not a feature ... one that i've reported to Apple a while ago already and that is being looked into. so not something that a guideline needs to take into account. (also, it's https://css-tricks.com/interaction-media-features-and-their-potential-for-incorrect-assumptions/ [edit: I just noticed you talked of anyway, related: https://bugs.webkit.org/show_bug.cgi?id=212580 |
|
I think that mobile device use and development have not been considered enough in standards even as large parts of the world are moving to mobile devices. Developer:
User:
Semantics: Again, please take a look at the code examples at appt.org to see what's been missing. The mobile group resources may also provide some fodder for thought. There are several spreadsheets linked on the MATF wiki page under "Current Work" |
This is not a reason for having "mobile" as a group/categorisation. Similar user concerns will happen with medium and large screens in different lighting conditions, potential distractions, other environmental factors.
Then, again, these user needs need to be considered for all similar situations, and not pigeonholed into "mobile". These additional considerations need to naturally be folded under more general categorisations (such as input), and provide sub-aspects there From a developer perspective, WCAG should be tech-agnostic in the first instance and provide high-level requirements that can apply to all different situations. How these then get realised - and, in particular, in native applications (both on desktop/laptop, mobile, tablet, large touch-enabled wall-mounted surfaces, etc) then comes under the tech-agnostic high-level requirement.
I don't think anybody was saying that these are the same, but that categorising things into am amorphous "mobile" bucket - rather than naturally adding different aspects/lived experiences/particular user needs when things are being used on a smartphone or tablet - is not ideal. |
|
Agree with all points.
But not sure why you think mobile hasn’t been involved - or taken seriously. We were working with mobile companies since way back in 2.0
One thing to also keep in mind - is that Mobile — is an undefined term — and needs to be broken out itself into is characteristics.
Some things to consider
There are "mobile" devices that are bigger than laptops now. (13 inch tablets and 12 inch and 10 inch laptops)
Laptops are mobile
Tablets and smartphones run the same OS but are completely different animals
Tablets run windows
Laptops run Android
Chromebooks are — well — chromebooks
I don’t think Mobile is the term we want to use going forward
Some suggestions to get he conversation going
Desktop operating systems (linux, windows, macOS) (open systems)
Vs
Sandboxed systems (where 3rd party AT doesnt work) (closed systems) (iOS, Android, Widows S)
Large screen (10 inches or more)
VS
Small screen (4-7 inches) (I know - there is a gap….that will be filled, maybe by folding screens - and is ambiguous)
Operated with Keyboard and Mouse or touchpad or touchscreen)
Vs
Operated by touchscreen, gestures and onscreen keyboard
Operated by voice
vs
Operated by devices
I can poke holes in all of the above as separations — and all are really spectrums. But you get the idea. It is not that it is "Mobile" that is important — but how what you are thinking of is different in some way from other devices — and whether our guidelines can apply across all of the above variations and combinations.
Other dimensions we should be thinking about?
gregg
———————————
Professor, University of Maryland, College Park
Founder and Director Emeritus , Trace R&D Center, UMD
Co-Founder Raising the Floor. http://raisingthefloor.org
The Global Public Inclusive Infrastructure (GPII) http://GPII.net
The Morphic project https://morphic.org
… On Aug 28, 2023, at 12:59 PM, Kim Patch ***@***.***> wrote:
I think that mobile device use and development have not been considered enough in standards even as large parts of the world are moving to mobile devices.
Here are some key points:
Developer:
Mobile developers have trouble following standards because there are still apples-to-oranges areas.
Mobile development is different and it's important that mobile developers be part of standards conversations.
I mentioned this resource because it fills in part of the gap: https://appt.org/en/docs
User:
Looking at a small screen in an office is different than looking at a small screen in the street.
Controlling a mobile device using a given input is often different from controlling a laptop/desktop using that same input (touch, speech, keyboard, mouse are the ones I can attest to myself).
Semantics:
This is a completely separate issue – I would agree that there doesn't need to be a mobile group if folks writing the standards have a good understanding of mobile device development and user needs, but saying mobile devices are the same as desktop/laptop form either a developer or a user point of view because you can plug a keyboard into a mobile device (how often are mobile devices used on the run?) doesn't sound like that to me.
Again, please take a look at the code examples at appt.org to see what's been missing. The mobile group resources may also provide some fodder for thought. There are several spreadsheets linked on the MATF wiki page under "Current Work <https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Main_Page#Current_Work>"
—
Reply to this email directly, view it on GitHub <#3 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNGDXR2IC7BIG5Z3CWQNXLXXT2DVANCNFSM6AAAAAA2S4DGLM>.
You are receiving this because you were mentioned.
|
|
Some good points have been made here already. The term "mobile" doesn't have a clear definition and the interpretation depends on the person you are talking with. The main issue I have with WCAG 2.x is the lack of techniques for native mobile applications. There are zero code samples in the technique resources. All code samples are focused on websites. Which is understandable, considering WCAG is part of the World Wide Web Consortium. The problem is that Section 508 and EN 301 549 have adopted WCAG for native mobile apps, but there is zero guidance for native app developers. This gap is something we are trying to close with the Appt code samples for WCAG which @KimPatch mentioned. With WCAG 3, we are (hopefully) moving towards better technology agnostic descriptions of requirements and solutions. The same applies to devices, I don't think we explicitly need to mention "mobile" devices, but from a user perspective we can mention narrow viewports and other characteristics. |
|
That is correct. WCAG is for web content — not software other than Webapps.
That is the WCAG2ICT was all about. And it tells you how to apply WCAG to software - but also notes that WCAG is not sufficient - that there are other aspects of software that are not covered because WCAG assumes there is a user agent
gregg
———————————
Professor, University of Maryland, College Park
Founder and Director Emeritus , Trace R&D Center, UMD
Co-Founder Raising the Floor. http://raisingthefloor.org
The Global Public Inclusive Infrastructure (GPII) http://GPII.net
The Morphic project https://morphic.org
… On Aug 29, 2023, at 12:47 AM, Jan Jaap de Groot ***@***.***> wrote:
Some good points have been made here already. The term "mobile" doesn't have a clear definition and the interpretation depends on the person you are talking with.
The main issue I have with WCAG 2.x is the lack of techniques for native mobile applications. There are zero code samples in the technique resources. All code samples are focused on websites. Which is understandable, considering WCAG is part of the World Wide Web Consortium.
The problem is that Section 508 and EN 301 549 have adopted WCAG for native mobile apps, but there is zero guidance for native app developers.
This gap is something we are trying to close with the Appt code samples for WCAG <https://appt.org/en/guidelines/wcag#guidance> which @KimPatch <https://github.com/KimPatch> mentioned.
With WCAG 3, we are (hopefully) moving towards better technology agnostic descriptions of requirements and solutions. The same applies to devices, I don't think we explicitly need to mention "mobile" devices, but from a user perspective we can mention narrow viewports and other characteristics.
—
Reply to this email directly, view it on GitHub <#3 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNGDXWGAVSID2AAWXPYFUDXXWNCPANCNFSM6AAAAAA2S4DGLM>.
You are receiving this because you were mentioned.
|
I don't think anyone is trying to say that mobile devices are the same as a desktop or laptop. It's more that the term mobile is ambiguous. What's important from a guideline point of view are the specifics of a given use-case or technology category. Examples
Device Context as a termIn these examples, the term "device context" serves instead of "mobile". "Device context" is technology agnostic, more comprehensive, and open to future technology shifts. Thank you for reading |
As we write guidance for pointers, gestures, and motion actuation, we should consider rethinking using the term "mobile."
https://lists.w3.org/Archives/Public/w3c-wai-gl/2023JulSep/0065.html
The text was updated successfully, but these errors were encountered: