Experts say don’t do infinite scrolling, or be extremely careful in doing so. I completely agree. Infinite scrolling creates accessibility and usability problems. Below are checkpoints, issues and suggestions from a few resources.
Replace automatic infinite scrolling with a “Load more results…” button or link that explicitly invites the user to add more. Once they do a few times, prompt them to ask if they’d like to turn auto-loading of more results on.
No, really, just don’t implement infinite scrolling.
It’s 2015, so hopefully web developers know that table elements should not be used for layout. There are many reasons why CSS for layout is better but at the core, HTML tables are data tables; they’ve always been meant for data.
But even today, sometimes a table is used for layout, for whatever reason—time constraints, lack of CSS skills, legacy code, etc.
If a table is used for layout, add ARIA role of presentation to the table element. This will remove the table elements from the Accessibility API which provides for a better user experience for users of assistive technology, particularly screen readers.
Other elements such as caption, summary, and thead should be removed. See the Microsoft resource ARIA Presentation Table Error.
Here’s a code example derived from a W3C example for the use of role=presentation. The following code in the HTML tree:
Apple has traditionally been a great advocate and model for accessibility and technology. Unfortunately this hasn’t been the case lately. One could even argue that default settings and recent designs are even counterproductive to accessibility progress. This includes VoiceOver, keyboard access, and design decisions.
Bug Infested
To begin, let’s reference a recent article by Marco Zehe where he explains major VoiceOver bugs in OS X 10.10 (Yosemite) and iOS 8. The two major examples he cites are:
When VoiceOver is running on the iPhone, using the Back button (or Scrub gesture to return to the previous page) will freeze VoiceOver.
When VoiceOver is running on the iPad, using Safari and the use of WebView components trigger app crashes and OS restarts.
In addition to bugs, I’ve noticed the following blatant accessibility problems pop up in Apple’s products. Each of these alone may not be a showstopper but collectively it shows a pattern of a company that doesn’t care, or pay much attention any longer; a company that’s losing its edge.
VoiceOver Hints
By default, VoiceOver places a large delay when announcing “hints”; this creates a huge lag for the reading of text defined by the aria-describedby attribute. And we all know that the support of aria-describedby is becoming more and more prevalent and essential in today’s world of modern web development. The delay is so long that it creates confusion; developers and testers very often think something is broken.
To “fix” the setting, you must find the deeply buried option and modify the delay time; in System Preferences, go to Accessibility / VoiceOver / VoiceOver Utility / Verbosity / Announcements (in OSX 10.9, it’s the the last setting).
.@abledaccess Yes. Stupidly, you must change the option under VO Utility/Verbosity/Announcements (last option). @LeonieWatson
A great example of Apple’s inaccessibility is the setting for keyboard focus; by default it doesn’t allow for typical keyboard navigation! A user cannot use the tab key to access all controls in an interface. In order to fix, one must again, search for the appropriate settings and modify. Again, this can be confusing and frustrating for developers and testers, let alone regular users.
To fix, the first step is to go to System Preferences / Keyboard / Shortcuts, and in the last section “Full Keyboard Access”, ensure the radio options “All Controls” is selected.
Let’s refer to the follow articles for more details on how to resolve which includes specific browser settings:
There are two major design issues by Apple recently which hinders accessibility: animations and parallax effects, and flat design.
There are many vestibular-related issues in Apple’s design, most notably during the release of iOS7. The issue continues to iOS8 although iOS settings are now available to help resolve the issue. To reduce parallax-type effects in iOS, go to Settings / General / Accessibility / Reduce Motion.
Also, iOS flat design (and the trend in general) is bad for usability and accessibility. Mostly because flat design creates ambiguity between elements; as the Nielsen Norman Group report states, “flat design hides calls to action“. And by implementing flat design, Apple indirectly encouraged others to do the same.
In addition to Nielsen Norman Group’s finding, another usability expert Steve Krug agrees that flat design is a detrimental practice. Here’s a quote from his book which was tweeted last May:
"Flat design makes it harder to differentiate things." ~Don't Make Me Think Revisited by @SKrug#dmmt#design#ux p153
Let’s hope Apple returns to the practice of releasing quality products: everything just works and accessibility is continually improving. And fair warning, after the mobile wars a few years ago, Google tops Apple in mobile operating systems; will accessibility be next?
Back in June of 2012, I wrote that the Placeholder Attribute Is Not A Label. The post points out that it’s bad practice to use text to look and behave as a placeholder rather than a label. This is generally known as “floating labels” or “inline labels” (I also call this LAP for short, “labels as placeholders”.) And as you may know, labels are required for accessibility (and usability) as they identify to the user what the input is for. It’s a general best practice to provide a label for every form input.
Unfortunately this design trend still continues even despite repeated concerns on use of placeholder from web development and accessibility experts. Web Axe too maintains that this pattern is bad for a variety of reasons which weren’t fully listed in the original post.
Sources of the Problem
Like many accessibility problems on the web, floated labels can be attributed to multiple issues. Firstly, web designs are trendy, and when a huge well-known company does something like floated labels (i.e. Apple), others follow, even if it’s a poor practice. And if usability testing is done and includes floated labels, it may not provide reliable results because the usability testing most likely:
is not done with long forms (which greatly increases the needs reviewing input and increases the potential of losing context)
is not done with users with disabilities
is not done with users with a situational disability
is done most likely in a controlled environment (latest browser provided, no chance for JS delays nor errors, guided by moderator, not a real product)
The web development community has a lack of adequate HTML skills which also contributes to this problem, so bad that articles recommending basic HTML practices must be written, and frankly, are much needed. A fundamental HTML practice is that a text input requires a label to define what it is. The intent of the placeholder attribute is very often misused; the W3C gives an explicit warning about placeholder:
Use of the placeholder attribute as a replacement for a label can reduce the accessibility and usability of the control for a range of users including older users and users with cognitive, mobility, fine motor skill or vision impairments
List of Pitfalls
Whatever the reason floated labels exist, here is a list of potential issues with the pattern.
The simple fact that since the label disappears when entering text, the user may forget what the input is for. This is especially important when reviewing form data; for users with a cognitive accessibility; and people who may be distracted when completing a form.
This pattern can’t support both a label and a placeholder.
Depending on user’s environment and implementation, there may be a delay in rendering/performance: on page load and in text disappearing after beginning typing. Or even it breaking entirely; see the two examples below.
If an HTML5 placeholder is used for label, older browsers and/or assistive technologies may not support it at all. For example, there is no placeholder support in IE9 and Opera Mini.
Placeholder text is rendered differently across browsers/versions; extra design and development is required to make them accessible (color contrast is usually very low) and have consistent styling. The traditional label is straight-forward and reliable.
Developing this pattern in the best way possible can be fairly complicated and is inconsistent among implementations. Code becomes heavier, more fragile, and more difficult to maintain.
The pattern doesn’t support standards; it doesn’t implement HTML elements and attributes as intended. The W3C HTML5 placeholder specification specifically states it should be a “short hint” of user input and states: The placeholder attribute should not be used as an alternative to a label.
In the Wild
No matter how many issues exist, the fact is that the floated label pattern is prominent on the web. Here are a couple of unique examples of this pattern in the wild which have completely gone wrong. This demonstrates only one of many issues with this pattern; sometimes the label doesn’t disappear visually and the label is blocking the view of the input text.
Attempts to Fix
Attempts have been made to help address or fix this problem, but not with much traction. One idea is to ask browsers to darken the placeholder text so that it passes WCAG color contrast requirement. This is a plausible suggestion but not likely to happen, especially any time soon. See below for the CSS fix. And doing so only addresses one issues; it wouldn’t fix the fundamental problem of the label disappearing.
Another attempt is to, upon focus of the input, reduce the text size of the floated label and move it to the bottom of the input field (rather than it disappearing entirely). This is not a feasible solution either as this behavior may cause confusion, requires text size that’s too small, and still adds code weight. Besides, if the label is going to remain visible near the input, it should just be there in the first place.
How to do it right
To create a form that’s robust and accessible, use the label and placeholder as intended:
The label element represents a caption in a user interface. It tells the user what the purpose of the input.
The placeholder attribute represents a short hint (a word or short phrase) intended to aid the user with data entry when the control has no value.
In the example below, the label “Enter URL” clearly indicates what the text input is for. The placeholder “http://” is a short hint as to what text should be entered. Also, a good guideline for placeholder text is similar to title attributes: only use them for supplementary information, not required information.
An exception to always displaying a visible label may be the search input where an icon (such as a magnifying glass) and the location of the form on the page visually denotes it’s meaning sufficiently. A visually hidden label is still required.
To better support mobile devices and screen enlarging tools, place the label above the input (as opposed to the left).
If using a placeholder (hopefully for the right reason), use CSS to darken the light grey so that it adequate color contrast. Here’s an example:
::-webkit-input-placeholder { /* WebKit browsers */
color: #666;
}
:-moz-placeholder { /* Mozilla Firefox 4 to 18 */
color: #666;
opacity: 1;
}
::-moz-placeholder { /* Mozilla Firefox 19+ */
color: #666;
opacity: 1;
}
:-ms-input-placeholder { /* Internet Explorer 10+ */
color: #666;
}
Summary
Please don’t use “floated labels” or “labels as placeholders” technique; it can break the user experience for a large variety of reasons. Use the label element and placeholder attribute as intended. Use CSS to ensure placeholder text has adequate color contrast.
Over the last year or so, a design trend in the web and mobile world has been transition animations, parallax effects, and the like. For many users, this can cause vestibular issues; the symptom is usually vertigo, or a feeling of motion sickness.
The issue was not well recognized until iOS 7 was released and overwhelmed users with an excessive amount of visual effects, especially parallax. Numerous articles were written about this issue, including iOS 7 and motion sickness by iMore. In a poll displayed on that article, about 28% of users reported having either mild or serious motion sickness with iOS7; this is not a formal study but still makes quite a statement. And at the time of writing, there are 100 comments on the article!
Pro tip! To reduce the parallax effect in iOS 7, go to Settings > General > Accessibility > Reduce Motion.
Pros and Cons
A study by Purdue University found that “although parallax scrolling enhanced certain aspects of the user experience, it did not necessarily improve the overall user experience”. Let’s take a look of pros and cons of parallax design.
Pros:
May possibly increase user engagement.
Cons:
Makes many users sick.
Requires additional code which makes web pages more complex longer to load.
Does not function smoothly across all browsers.
Difficult to implement with responsive and mobile design.
Can make it difficult or frustrating for the user to consume content due to excessive scrolling.
Recommendation
There are obviously many more negative points for using parallax design as there are positive. My recommendations are:
Use parallax effects (and animations) with much discretion and tolerance, if at all.
Ensure complete browser testing on desktop as well as mobile devices.
UPDATE: The CSS Reduced Motion Media Query can now be used to turn off (or reduce) animation and motion effects when a user has the setting on in the user agent, if supported.