Skip to content
This repository has been archived by the owner on Jun 30, 2018. It is now read-only.

Familiar design (Enhanced) #35

Closed
lseeman opened this issue Nov 27, 2016 · 13 comments
Closed

Familiar design (Enhanced) #35

lseeman opened this issue Nov 27, 2016 · 13 comments

Comments

@lseeman
Copy link
Contributor

lseeman commented Nov 27, 2016

SC Shortname: Familiar Design (Enhanced)

SC Text

Familiar design (Enhanced): Navigation mechanisms and common icons are easily identifiable and available to the user in one or more of the following ways:

  • Platform specific: A platform specific user interface design.
  • An adaptive user interface design that can be personalized.
  • User interface from a prior version: A user interface design that was used successfully by users in a prior version of the application.


An exception is available if the style is an essential part of the main function of the site, such as for a game.

Alternative wording

A familiar layout of navigational elements and common icons are easily available such as: the standard for the user platform or, a previous versions of this product that the user is familiar with and has successfully used.

Suggestion for Priority Level:

AA

Related Glossary additions or changes

common icons

What Principle and Guideline the SC falls within.

Principle 3, Guideline 3.2: Predictable

Description

The intent of this success criteria is to ensure a clear relationship between the cues provided for navigation and the intended action. Icons, symbols and other mechanisms used for navigation should be consistent throughout a platform. If abstract designs are used, alternatives should be provided that are understandable to as many users as possible.

The intent is to help as many users as possible understand the site and know how to use it. This often involves using things that are clear and familiar to the user so that they do not have to learn new symbols, terms or design patterns. As many users, for example, people with memory impairments such as dementia, cannot learn new designs, this is essential for them to be able to use the content. Personalization and good use of semantics can help make symbols and design as familiar to the user as possible.

Many people cannot easily learn new design metaphors or remember things that they have learned for example, people with Mild Cognitive Impairment (MCI) or dementia. Without these skills it can be much harder or impossible to:

  • Locate desired items to interact with
  • Know what the interaction will do

Using familiar design, terms and symbols is key to being able to use the Web for people who cannot remember new symbols for example, some people with memory related impairments like dementia. Therefore this success criteria addresses the user need tfor hings to be familiar including:

  • Location of elements
  • Symbols

Note: Familiar text is addressed in another SC.

An adaptive user interface design which changes based on user preferences allows users with a variety of cognitive disabilities to adjust an interface based on their specific needs. Various platforms may offer guidance for creating user interface designs. Following such guidelines helps to create consistency not only within a single application but across multiple applications. These guidelines reinforce consistency which is known to have a positive impact on users with a variety of cognitive disabilities.

It should be noted that the task force has worked to show the viability of easy personalization with:

  • Easy to tailor symbols, user interface for user profiles
  • Easy to get help that works for this user profile
  • General help and context sensitive help

JSON is being used for collections of name/value pairs for each skin.

We are also standardizing the relevant semantics and personalization settings to support alternative implementations.

Benefits

Consistent navigational cues benefit all web users, providing clear, effective and efficient way finding. It has particular benefit for those who have cognitive impairments, which may have an impact on memory, visual and auditory perception and comprehension. These users should not be faced with barriers such as complex abstract imagery or ambiguous navigational elements.

For example, a user may have used an email program for the last few years. Now the interface has been updated and with these changes the user needs to learn new icons, and navigation. If the user is learning impaired or has an impaired memory and is not able to learn the new navigation this may keep them from reaching and using the content.

As one user with mild dementia stated "I have great difficulty remembering things, working things out, and interpreting things."

As long as interfaces are familiar the user can continue to use the Web.

Using common icons in the expected position help. But, because what is familiar to one person may not be familiar to another person enabling personalization of icons is the most useful approach.

Related Resources

Resources are for information purposes only, no endorsement implied.

Testability

Identify any icons and navigation element. Where item 1, 2 or 3 can be applied, confirm that either item 1, 2 or 3 bellow is true for each icon and navigation element:

1. The icons and navigation conforms to a standard identified in a WCAG technique or the UI standard of the native platform

2. Semantics are used to enable personalization

3. A role back option to the previous interface that has been in use by the user is available (this case the role back user interface must have been widely used)

Techniques

The more predictable your content is the easier it is to know how to use it.

  • Using COGA semantics such that common components and icons programmatic determinable enables their positions to be standardized via personalization.

  • Use standard Web layout design, so it is easy to find common content. In 2015 in English sites this includes:
    • The search box is in the right hand corner
    • A link to home page in the left hand corner
    • The site map in the footer, etc.
    • Main menus are at the top of the page under the log and search or on the left hand side.
    • Links are underlined
    • Using common icons :
      • Icons used in a standard or common operating system.
      • A question mark for help
      • An exclamation mark for warnings
  • For iOS on each screen UI Bars, UI Views and UI Controls align with iOS Human Interface Guidelines

Follow the standard user interface guidelines for a specific platform.

working groups notes (optional)

The reword document also includes the following notes:

Add at level A

Familiar layout: Help, navigation to help and search forms are easily identifiable and available to the user in one or more of the following ways:

  • Platform specific: A platform specific user interface design.
  • Adaptive: An adaptive user interface design.
  • User interface from a prior version: A user interface design that was used successfully by users in a prior version of the application.
@DavidMacDonald
Copy link
Contributor

The SC appears to say Level A, but the title is AA

@lseeman
Copy link
Contributor Author

lseeman commented Dec 2, 2016

Should be AA

Do you want us to change it in the text?

@lseeman
Copy link
Contributor Author

lseeman commented Dec 2, 2016 via email

@lseeman lseeman changed the title Familiar design (AA) Familiar design (Enhanced) Dec 14, 2016
@joshueoconnor
Copy link
Contributor

Assigned to Thaddeus Cambron (@inclusiveThinking) https://www.w3.org/WAI/GL/wiki/SC_Managers_Phase1

@detlevhfischer
Copy link
Contributor

My suspicion is that "Navigation mechanisms and common icons are easily identifiable" is not something that would be testable in a clear-cut way. Will icons be common or not? Except a few where we have some fairly conventional solutions (think loupe, home, on-off switch, menu) it depends on the complexity of the application how many different icons there will be, and the more complex the app, the less likely that all its icons will be common and easy to identify. (I take it that 'navigation' here means not just moving within a static set of pages but might include functions such as sorting, bookmarking, sharing, resetting, looging in/out etc). What the SC must avoid is demanding commonality of icons in cases of content that happens to be complex. (I would understand if there is a requirement that a text equivalent of any icon has to be available for the user, whatwever that means precisely).

What is not quite clear in the text is whether the SC wants to address the type of icon or the exact instance implemented. Take loupe and loup instances: One may be held by Sherlock (too complex, because not abstract enough?), another may have such a short stub that it hardly looks like a loupe, etc.

I find it quite hard to visualise what some of the expressions in this SC refer to - things like "cues provided for navigation and the intended action" or "complex abstract imagery or ambiguous navigational elements". Cues overlap with things like indiciation of position via breadcrumb or markers on menus, unvisited / visited links covered already elsewhere, for example in SC 2.4.8.

The call for consistency throughout seems already covered in 3.2.3 Consistent Navigation - but in any case, it is not entirely clear what is meant by "should be consistent throughout a platform" if we are talking web content that is expected to run on various platforms and in various browsers. I think what must be meant is "internal consistency" of icons within a site or app, across pages / views, independent of platform, but maybe you had something else in mind.

Some of the most common navigational elements (icons), like arrows, can be ambiguous, depending on context (a left arrow can mean "go back (to where you came from)" or "go to adjaent previous element") and I wouldn't be clear whether you would consider them abstract. What is the abstract imagery that you would like to be able to fail in such a new SC or where "alternatives should be provided that are understandable to as many users as possible"? Examples would really help.

Other icons are abstract and conventional and even purposefully non-specific: I think of the share icon that is used so much today and usually brings up another choice (via mail, whatsapp etc) in a second step.
It is not certain to me that any attempt at an alternative (bar exchanging it for plain text) is likely to be better. Again, real examples would help. So far this seems all quite vague.

User interface from a prior version:
As to design changes compared to older, familiar versions, I think it would be overreaching if a tester failed a new interface because it has updated icons without a customisation option - one that supposedly should work across platforms and browsers (including mobile). Arguably the degree of the intellegibility of icons is basically a statistical matter with a steadily changing reference field. To be clearer, today, a 'Hamburger' item is understood by a high percentage of users because it is used pervasively´. Fve years ago most would have struggled to guess what it does. So software or sites cannot be just hold on to the standard they have once established - they want to (and should, IMO) change in view the the field they are in, and that makes sense because users do not interact with just one application or site, but with many in the field.

@inclusiveThinking
Copy link

@detlevhfischer do you have suggested updates based on your input that I can suggest to the group to address your concerns?

@DavidMacDonald
Copy link
Contributor

How far back should versions of old software go back? One version, just the last version, or more? It's basically saying "don't do anything innovative to the UI, unless it is what the OS is already doing or unless its the same as your previous version, or the user can do Personalization which is not yet mature and achievable .... DEVs have a hard enough time creating a style switch to inverse colours. I don't know how it can be made to meet the SC acceptance criteria. Perhaps we should wait on this until a high degree of personalization becomes achievable and practicable for authors.

@inclusiveThinking
Copy link

The SC indicates rollback to a prior version used successfully by user. Organizations will have some sense of the level of success of prior effectiveness based on user engagement. Rollback is only one option. The SC is not saying don't do anything innovative to the UI. It is in part encouraging the use of a sites existing UX patterns which has benefit to all user but particular for users with cognitive disabilities.

@detlevhfischer
Copy link
Contributor

detlevhfischer commented Feb 2, 2017

"Navigation mechanisms and common icons are easily identifiable":
If there is neither a customisation option that would allow replacing icons with a set of icons familiar to the user nor a rollback option (there rarely is), then the test might compare icons to the set of standard controls (compare #36 Clear controls) to assess whether they can be easily recognised.
This would help identify wacky and odd versions (of home icon, loup icon, arrows etc.) such as a loupe with a very short handle which is not easy to identify as loupe.
It will still be hard to draw the line conclusively, i.e. determine that an icon is too far off the standard control to pass the SC. (There could conceivably be image recognition algorhithms at work here, at some point.)

@inclusiveThinking
Copy link

#49 (comment)

@joshueoconnor
Copy link
Contributor

@inclusiveThinking Can you give me a status update on this please? Will there soon be a PR on this or do you need more time?

@inclusiveThinking
Copy link

I will make a PR this eventing

inclusiveThinking added a commit to inclusiveThinking/wcag21 that referenced this issue Feb 19, 2017
Familiar Design - Enhanced w3c#35
@inclusiveThinking
Copy link

@joshueoconnor a Pull Request has been initiated

@ghost ghost assigned ghost and unassigned inclusiveThinking Apr 14, 2017
@awkawk awkawk added the Defer label Aug 24, 2017
@awkawk awkawk closed this as completed Aug 24, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants