Comments on Mobile Accessibility Note 20150226
Mobile Accessibility Note (Github)
Comments submitted from Github
Comments submitted from EOWG
Melody's Comments
Key observations:
I like how the document flows and addresses the issue in a very readable and comprehensive way. On the other hand, on more than several occasions, the document recommends too specific techniques that are often poor development and UX practices. These need to be reviewed. There are some significant technical issues with this document, especially when it uses words like "small screen sizes" or "'mobile' screen sizes". My detailed comments of this issue is recorded in the inline comments below. Sometimes it's hard to distinguish what is being described as a default OS/platform feature vs. "other applications/sites" that people have developed to demonstrate poor execution vs. what the developer reading this should do for their application/site. Examples given were sometimes too specific and should be brought up at a higher-level when the set of examples are not comprehensive or all encompassing of all the techniques that can achieve the general recommendation. Readers may get distracted away from the actual higher-level message of the passage when very specific examples are given.
Typos submitted as pull request on Github: https://github.com/w3c/Mobile-A11y-TF-Note/pull/2
Mobile Accessibility: How WCAG 2.0 and Other W3C-WAI Guidelines Apply to Mobile
1.1 WCAG 2.0 and Mobile Content/Applications
"web pages utilizing responsive design can transition into a "mobile" screen size even on a desktop/laptop"
[Comment: "Mobile" screen size is the wrong term here. When browser viewport is resized or zoomed in, a site using responsive design can reflow to layout that is optimized for a smaller screen-size typical of a mobile device. The desktop screen will always be as big as the screen of the desktop, it’s the browser viewport that is changing.]
1.2.2 ATAG 2.0 and Accessible Mobile Authoring Tools
[Comment: Give an example of what an authoring tool is, similar to the examples in the UAAG section.]
Discussion of Mobile-Related Issues
2.1 Small Screen Size
[Comment: What is considered small screen size vs medium vs large? Screen sizes are generally blurring across the spectrum. http://www.fastcodesign.com/1673162/the-disintegration-of-android-visualized#1]
"While the exceptional resolution of these screens theoretically enables large amounts of information to be rendered," [Comment: Not sure what this actually means in terms of large amounts of information. High resolution screen size has little to do with screen real estate for content. Other advantages and problems result from variance in screen resolution. Also, a small screen size, doesn’t equal better resolution. A 15” retina MacBook pro has better resolution than an iPhone 4. Therefore, I don’t think this sentence is needed here.]
"Minimizing the amount of information that is put on each page compared to desktop/laptop versions by providing a dedicated mobile version or a responsive design:"
[Comment: From a good user experience and user interface perspective, you want to provide consistent user experience regardless of screen sizes yet tailored to use case for the device (i.e. using a site on a wearable vs. mobile phone vs. desktop may have different use cases). However, that doesn't mean that you should reduce amount of information. A best practice is to design sites with mobile in mind first and rethinking the content layout and relevancy of content rather than “amount of information”. Take Instagram for example, the content on their mobile app is richer than the content on desktop. Therefore, this statement is already nullified.]
"For example, on narrow screens the navigation menus may be hidden until the user taps a menu button."
[Comment: For example, on narrow screens the navigation menus may be hidden until the user taps a menu button. Off-canvas navs are actually being re-evaluated for it’s effectiveness right now. Apple actually discourages its use: http://blog.manbolo.com/2014/06/30/apple-on-hamburger-menus and it's shown to be ineffective in user testing: http://exisweb.net/mobile-menu-abtest]
"Adapting the length of link text to the viewport width"
[Comment: Unsure about what this recommendation is trying to convey. Text usually wraps if it’s a responsive site or mobile site. It may also be too specific for this section.]
"Positioning form fields below, rather than beside, their labels (in portrait layout)"
[Comment: I wonder if these examples are too specific and more high-level examples should be provided instead. A high-level best practice would be something like: “Do not disable zoom so that low vision users can use your site.”]
2.2 Zoom/Magnification
"A variety of methods allow the user to control content size on mobile devices with small screens."
[Comment: Remove “small screen”. Clarification is need that these “methods” are already built into OS/browsers as features and these are not methods that the developers should build. In fact, the guidance should be that developers and designers should not try to override these default behaviours or build apps/sites in conflict and instead should design/develop with these accessibility features in mind.]
"Set default text size (typically controlled from the Display Settings) Note: System text size is often not supported by mobile browsers."
[Comment: Need to explain that Display Settings and Accessibility Settings is being referred to the OS’ options. Also, consider no capitalization since the naming of these can differ from OS to OS.]
From working group 2015-03-26 Meeting: First bullet covers concern that the document doesn't cover browser options. Made changes to bullets to clarify, including "at least 200%"
"For instance, the default point size for mobile platforms might be larger than the default point size used on non-mobile devices."
[Comment: "Point size" should probably be more generic as "text size". Mobile platforms vs. non-mobile devices are not comparable.]
From working group 2015-03-26 Meeting: Made change in second paragraph to "text size"
"When determining which contrast ratio to follow, developers should strive to make sure to apply the lessened contrast ratio only when text is roughly equivalent to 1.2 times bold or 1.5 times (120% bold or 150%) that of the default platform size."
[Comment: This is the shared responsibility of designers, developers, product managers etc. to uphold this guideline. This sentence should not mention developers specifically, because more often than not, such design decisions are made elsewhere by other stakeholders and simply executed by developers.]
"However, keyboard accessibility remains as important as ever and most major mobile operating systems do include keyboard interfaces, allowing mobile devices to be operated by external physical keyboards (e.g. keyboards connected via Bluetooth, USB On-The-Go) or alternative on-screen keyboards (e.g. scanning on-screen keyboards)."
[Comment: Is this sentence specifically mentioning physical keyboards? All major mobile operating systems offer soft keyboards. This section needs updating for soft keyboard guidance. For example, you can’t tab through things when using a soft keyboard, so some of the WCAG criteria may actually not apply.]
3.2 Touch Target Size and Spacing
"The high resolution of mobile devices means that many interactive elements can be shown together on a small screen."
[Comment: Resolution has nothing to do with screen real estate.]
3.3 Touchscreen Gestures
"Many mobile devices are designed to be primarily operated via gestures made on a touchscreen."
[Comment: Maybe this should just say touchscreen devices since there are now many desktop devices that are touch-enabled.]
"Some best practices when deciding on touchscreen gestures include the following:"
[Comment: Are there other best practices? Will there be a link to them?]
4.5 Provide clear indication that elements are actionable
"Existing interface design conventions are aimed at indicating that these visual elements are actionable. The principle of redundant coding ensures that elements are indicated as actionable by more than one distinguishing visual feature. Following these conventions benefits all users, but especially users with vision impairments."
[Comment: Unclear what “existing interface design conventions” mean and how “redundant coding” ensures that? You can have DRY code, but not following existing design conventions at all.]
"Visual features that can set an actionable element apart include shape, color, style, positioning, text label for an action, and conventional iconography."
[Comment: Styling for statefulness of touch elements is probably one of the most important visual features, but not specifically mentioned here.]
"Conventional shape: Button shape (rounded corners, drop shadows), checkbox, select rectangle with arrow pointing downwards"
[Comment: Not all browsers support rounded corners and drop shadows. Probably not the best example. "Select rectangle” is also unclear. I'm assuming that this is referring to the HTML “select element”.]
"Iconography: conventional visual icons (question mark, home icon, burger icon for menu, floppy disk for save, back arrow, etc)"
[Comment: The burger icon is actually not a good design pattern. From user testing perspective, it’s been indicated that many people don’t know what it’s for. http://www.peakusability.com.au/articles/mobile-ux-part-1-menu-burgers-and-navicons. The floppy disk is also an outdated icon since we don’t use floppy disks any more.
Lastly, icons don’t always indicate interactivity on its own. You can have a star rating that is to show the current rating of a product, but the user can't actually interact with it.
This section is also missing one of the most important distinguishing features - stateful styling. Once of the most criminal practices is building things that are activated by hover on mouse, which can’t be accessed by touch on touch devices.
https://developers.google.com/web/fundamentals/input/touch/activestates/
Text labels could also be a distinguishing feature.]
5.3 Support the characteristic properties of the platform
"Mobile devices provide many features to help users with disabilities interact with content. These include platform characteristics such as zoom, larger fonts, and captions. The features and functions available differ depending on the device and operating system version. For example, most platforms have the ability to set large fonts, but not all applications honor it for all text. Also, some applications might increase font size but not wrap text, causing horizontal scrolling."
[Comment: This should be changed to guidance of what you should do vs. what people do wrong.]