Familiar Design (Minimum)

[lseeman]

SC Shortname: Familiar Design (Minimum)

        <h2><a id="user-content-sc-text" href="https://github.com/w3c/wcag21/wiki/Proposals-for-new-Success-Criteria#sc-text"></a>SC Text</h2>
              <p><strong>Familiar design (Minimum): </strong> Help,  navigation to help and search forms are easily identifiable and   available to the user in one or more of the following ways:</p>
                  <ul>
                    <li>Platform specific: A platform specific user interface design.</li>
                      <li>Adaptive interface: An adaptive user interface design that can be personalized.</li>
                      <li>User interface from a prior version: A user interface design that was used successfully by users in a prior version of the application.</li>
                  </ul>
                  <p><br>

Exception: The style is an essential part of the main function of the site, such as for a game.

Suggestion for Priority Level:

              <p>A</p>
        <h2><a href="https://github.com/w3c/wcag21/wiki/Proposals-for-new-Success-Criteria#related-glossary-additions-or-changes"></a>Related Glossary additions or changes</h2>

Help: a mechanism provided to give a user access to help content, a support page or a support function

        <h2><a href="https://github.com/w3c/wcag21/wiki/Proposals-for-new-Success-Criteria#what-principle-and-guideline-the-sc-falls-within"></a>What Principle and Guideline the SC falls within.</h2>
        <p>Principle 3, Guideline 3.2: Predictable</p>
        <h2><a href="https://github.com/w3c/wcag21/wiki/Proposals-for-new-Success-Criteria#description"></a>Description and Benefits</h2>
        <p>Many people cannot easily learn new design metaphors or remember  things which they have learned for example, people with Mild Cognitive Impairment (MCI) or dementia. Without these skills it can be much harder or   impossible to: </p>
            <ul>
              <li>Locate desired items to interact with and </li>
              <li>Know what the interaction may do.</li>
            </ul>
            <p>However at a minimum level (Conformance level A) as many users as possible should be able to reach help and a search mechanism.</p>
            <p>Using a familiar design, terms and symbols is key to being able   to use the Web for people who cannot remember new symbols for example, people with memory related impairments like dementia. Therefore, this success criteria addresses the   user need for things to be familiar including:</p>
            <ul>
              <li>Location of elements</li>
              <li>Symbols </li>
            </ul><p>
            When an author is creating a platform specific UI, the look and feel of these features should appear and operate in a manner which is consistent with the platform or be capable of being personalized. The only exception would be a design that has been proven through user testing to be intuitive and easy to use even though it departs from that of the platform.  </p>
                <p>COGA is also working on standardizing the relevant semantics and personalization settings to support alternative implementations.</p>
            <p>&nbsp;</p>
        <p>See <a href="https://w3c.github.io/wcag/coga/user-research.html">User research</a> </p>
        <p><a href="https://rawgit.com/w3c/coga/master/gap-analysis/">Gap analysis </a></p>
        <ul>
              <li> <a href="https://rawgit.com/w3c/coga/master/gap-analysis/table.html">User needs Table:</a>6, 7,8 and 9</li>
              <li><a rel="nofollow" href="https://w3c.github.io/wcag/coga/user-research.html">Background research document</a></li>
              <li> <a rel="nofollow" href="https://w3c.github.io/personalization-semantics/">Semantics for adaptive interfaces</a></li>
            </ul>
        <h2>Related Resources</h2>
            <p>Resources are for information purposes only, no endorsement implied.</p>
            <ul>
                <li><a rel="nofollow" href="https://developer.apple.com/ios/human-interface-guidelines/visual-design/layout/">iOS Human Interface Guidelines</a></li>
                <li><a rel="nofollow" href="https://developer.apple.com/xcode/interface-builder/">Xcode - Interface Builder</a></li>
                <li><a rel="nofollow" href="https://developer.android.com/guide/practices/ui_guidelines/index.html">Android User Interface Guidelines</a></li>
                <li><a rel="nofollow" href="https://msdn.microsoft.com/en-us/library/windows/desktop/dn742479(v=vs.85).aspx">Microsoft Windows - UX Checklist</a></li>
                <li><a rel="nofollow" href="https://www.nngroup.com/articles/the-need-for-web-design-standards/">Nielsen Norman Group - The Need for Web Design Standards</a></li>
                <li><a rel="nofollow" href="https://w3c.github.io/wcag/coga/user-research.html">Background research document - 3.7.6.1 Consistency</a></li>
            </ul>
        <h2><a id="user-content-testability" href="https://github.com/w3c/wcag21/wiki/Proposals-for-new-Success-Criteria#testability"></a>Testability</h2>

Test procedure

            <p>Identify any  help,  navigation to help and search forms . Where item 1, 2 or 3 can be applied, confirm that either item 1, 2 or 3 below is true for each  help and search element:</p>
            <p>1. The icons and navigation conform to a standard identified in a WCAG technique or in the UI standard of the native platform</p>
            <p>2. Semantics are used to enable personalization</p>
            <p>3. A roll back option to the previous interface that has been in use by the user is available (in this case the roll back must be to a user interface that has been previously widely used)</p> 
        <h2><a id="user-content-techniques" href="https://github.com/w3c/wcag21/wiki/Proposals-for-new-Success-Criteria#techniques"></a>Techniques</h2>
            <p>The more predictable your content is the easier it is to know how to use it. </p>
      <ul>
        <li>Using standard Web layout design, so it is easy to find the help and search. In 2015 for English sites this includes: 
          <ul>

The location of the search box is in the top right hand corner

A question mark as the graphical symbol for help, etc

Using COGA semantics such that search and help components and icons are programmatic determinable and that their positions can be standardized via personalization

Following the standard user interface guidelines for a specific platform. See also:

• iOS UI Bars
• iOS UI Views
• iOS UI Controls

Follow the standard user interface guidelines for a specific platform.

working groups notes (optional)

[joshueoconnor]

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

[inclusiveThinking]

Should the success criteria also include site navigation? The SC would read: "Help, site navigation and search forms are easily identifiable and available to the user in one or more of the following ways:

[lseeman]

I think that was at the next conformance level?

All the best

Lisa Seeman

LinkedIn, Twitter

---- On Sun, 22 Jan 2017 09:39:31 +0200 Thaddeus<notifications@github.com> wrote ----

Should the success criteria also include site navigation? The SC would read: "Help, site navigation and search forms are easily identifiable and available to the user in one or more of the following ways: — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[lseeman]

If not maybe we should add it? although it makes it harder for developers -that is why adding navigation was at AA

[inclusiveThinking]

I checked Familiar Design (Enhanced) It does discuss navigation. I would think navigation might be an A however recall we agreed within in the TF to make it AA.

[patrickhlauke]

For completeness, adding my comments here from the November 2016 survey:

The SC seems quite disjointed. the normative text refers only to "Help, navigation to help and search forms", but later text seems to imply it applies to the entire layout/UI.

Providing roll-back to previous layouts/look and feel, and full interface customisation are extremely onerous from a technical standpoint to mandate for all sites.

There is vague talk of "semantics" being standardised for use. What is referred to here? Correct use of HTML and/or ARIA landmarks/roles (already covered by 1.3.1 and 4.1.2, arguably)? Or something more "bespoke", i.e. microformats or similar? And if so who's standardising these, and is this SC essentially mandating the use of some microformat/RDF/schema?

[lseeman]

@patrickhlauke the specification is in the links. see https://w3c.github.io/personalization-semantics/ it is under the aria working group. A first open implementation is at https://github.com/ayelet-seeman/coga.personalisation and there is a demo at http://rawgit.com/ayelet-seeman/coga.personalisation/demo/conactUs.html IBM and Pearson are saying they intend also to implement it. Not having a roll-back is only one of the ways to conform. so if t is too hard choose the other ways

[patrickhlauke]

So in essence unless a site uses very specific icons, adopts the proposed coga- attributes, or provides rollback, it fails? This seems a very hard thing to impose on all sites at level A

[lseeman]

not more so then aria. Use the semantics (or some other semantics or personalization method if it exists) And let more people use your content. why is it ok to expect people to do work for some disabilities and not for others?

[patrickhlauke]

not more so then aria.

for most cases, there are things that can be done other than through the use of aria (e.g. using existing HTML semantics correctly to satisfy 4.1.2/1.3.1 etc).

here, unless authors opt for coga- which can add semantics "invisibly", it seems that the only other option is to impact the layout/design/structure (use of an explicit set of icons, customisation/personalisation of its own, or rollback). there's no other way for authors to fulfill the SC with some alternative "semantics" as there are no other semantics that are standardised and as granular as proposed here. and since coga- is not yet standardised or widely supported, it feels a bit risky to make it one of the fundamental technologies that most appropriately satisfies the SC.

making this a level A will mean that all sites currently in existence will have to do work to even pass A, and until coga- is established as a standard and user agents for it are readily available on all common platforms/as add-ins for user agents/etc, the only way for sites to comply would be to change their design/iconography or, if not already present (which is the case for most sites), implement a customisation or rollback system.

i would foresee this getting quite a bit of pushback.

[lseeman]

Hi, we are making a free browser extension. It should be done in March - well before CR

[patrickhlauke]

For a spec (thinking of the COGA semantics one) to get on REC, you'd generally need at least two interoperable implementations. And it still feels that you're essentially mandating sites to use a new spec you created for this purpose, which is only (?) supported by an extension that you created for this purpose. Still want to raise this as a concern for possible wider pushback.

[inclusiveThinking]

@patrickhlauke I have read your concerns. Do you have any suggestions for updates of the SC that may facilitate adoption and lead to less pushback? Would you like broader socialization and if so can you recommend other members that may be interested in reviewing and commenting on this SC that may lead to moving forward?

[patrickhlauke]

@inclusiveThinking my main concerns, in a nutshell, are: barring the use of a proposed standard which is not yet stable and has only one (?) experimental implementation so far, all other ways to satisfy this will require sites to modify their design and functionality. as such, i personally feel it's unrealistic to get widespread buy-in from the larger web community (both large content providers such as Facebook, Google, etc, and smaller content providers / individual web designers). If it is at A, this could become a serious sticking point for sites deciding to remain compliant only with WCAG 2.0 instead of adopting 2.1.

If there were a way to satisfy this without impacting design/functionality even today - for instance, by leveraging existing ARIA role attributes, HTML semantics, etc - anything that may already be considered good semantic markup practice today - I'd have slightly less concerns. This may involve revisiting how user agents / extensions that aim to provide the user with personalisation functionality can infer meaning/author intent from these existing structures (rather than insisting on authors having to go an revisit all their existing content to add new coga- attributes). A sort of gap analysis of how far meaning/intent can be inferred even without explicit coga- attributes may be useful.

And it may be worth to explicitly ask for feedback from big platforms such as Facebook, Google, and co.

[inclusiveThinking]

Thanks for the input. My experience is that the concept of familiar design and the use of UX patterns has benefit to all users, is a known practice within the field of UX and has particular benefit to users with cognitive disabilities. Typically large platforms or enterprise Websites implement site redesigns using an iterative approach wherein the designs of smaller features are updated within the context of multivariate testing and data is collected and analyzed to gauge benefit to users or user adoption. Given your feedback and knowing that many users have pattern seeking tendencies when interacting with a UI maybe the larger group can give input on additional points that can help us move forward. It may be useful to note that the SC criteria states "... available to the user in one or more of the following ways: ... " and then states three ways. Maybe a fourth or fifth is needed.

[awkawk]

I'm quite concerned about this SC proposal. Some questions: 1) This applies to "help" - what exactly does that mean? WCAG is applied on a page-by-page basis, so it applies to web pages that are part of a help system? Is that all? 2) What exactly do we mean by "navigation to help"? 3) "search forms" is more clear, but what if it isn't in a form element? Do you mean "search functionality"? 4) Is there a platform-specific pattern for help, navigation to help, or search forms that we can point to? 5) How do we think that anyone would assess whether a UI design was used successfully in a prior version? I suspect that this effectively means that any design that was used before is grandfathered.

[lseeman]

1-2 , Thadd can you add a glossary to what we meen by "help" and "navigation to help"? 3, form should at least be in a container with a landmark role of search

4. yes, as a techneque 5, analiticsa, tracking or if it is an eterprize sofwere they can just ask. Basicly it meens when you update a ui, make sure people still can get to help

[lseeman]

@patrickhlauke that is why we have such a limeted scope of find help and search at level A. The techneques headers give ideas for more , but here we are saying use a well know icon or emerging personlisation, or a role back, or allow for your own icon/ format change for these limited things.

[inclusiveThinking]

@lseeman preparing to add the following definition of help. This is taken from one or our SC specific to help: Help - A mechanism provided to give a user access to help content, a support page or a support function that is reachable with one user action.

[patrickhlauke]

reachable with one user action

What constitutes "one user action"? If a user has to, say, hit TAB two times and then ENTER to activate a link, how many actions is that?

[inclusiveThinking]

user action: the intentional interaction taken by the user to manipulate the content of the page.

[patrickhlauke]

sure, but "one" ? what constitutes "one"?

[awkawk]

@inclusiveThinking I don't think that @patrickhlauke is deliberately trying to be difficult. This is the level of detail that we need to get into. We can do it in the group, or we can wait for it to appear in public comments and then deal with it in the group, but dealing with it is inevitable. Sorry! :)

[patrickhlauke]

Your comment seems the first mention of "one user action" on this particular thread. I am asking for clarification what constitutes one user action. Taking the example of a link which is in the third tab order on a webpage, does the fact that a keyboard user has to press TAB two times (to set focus to said link) and then ENTER to active the link constitute, as a whole, one action, or not? i.e. would this pass or fail? And if it fails, does it mean that no matter where a user is within a page, there must always be a single action they can take to trigger help, and how should that be achieved? an accesskey? What about platforms where this is not supported, such as mobile/touchscreen?

[inclusiveThinking]

@patrickhlauke I apologize for using the term rant.

[patrickhlauke]

no worries @inclusiveThinking - i do tend to come across rather abrupt sometimes.

[detlevhfischer]

I am replicating my comment from #35 Familiar design (enhanced) here. "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]

Thanks Detlev. If I am understanding you correctly, you have concerns around the availability of customization, similar to @patrickhlauke, and the roll back options but think there may be some value (but somewhat inconclusively) in testing against standard controls. Are you suggesting adding the test against standard controls to the Testability section and possibly - "Use of standard controls" to the SC text?

[joshueoconnor]

@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]

I will make a PR this eventing

[joshueoconnor]

Thanks Thaddeus @inclusiveThinking

[lseeman]

@patrickhlauke and @detlevhfischer would you prefer this wording?

Familiar design (Minimum): 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. An adaptive user interface design that can be personalized. A standardized technique or design pattern User interface from a prior version: A user interface design that was used successfully by users in a prior version of the application. Exception: The style is an essential part of the main function of the site, such as for a game.

We can define "A standardized technique or design pattern" as A standardized technique or design pattern that is either:

• recommended in a wcag technique (techniques can be submitted by any other standard and just approved by wcag) or
• by the user platform
• or in a W3C note

If we like it we can reuse for all the familiar design SC's

[inclusiveThinking]

Is it possible to get feedback on this? My understanding is that I need to do another Pull Request ASAP. Thanks!

[lseeman]

I think you can make a pull request with Consistent position: Common navigation, search, and control elements have a consistent position within a set of web pages unless a change is initiated by the user

the pull request lable can be anything you want that makes sence. I would say "Consistent position - was issue 29" - that give the new name but helps with tracking

All the best

Lisa Seeman

LinkedIn, Twitter

---- On Thu, 09 Feb 2017 08:21:49 +0200 Thaddeus<notifications@github.com> wrote ----

Is it possible to get feedback on this? My understanding is that I need to do another Pull Request ASAP. Thanks! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[patrickhlauke]

We can define "A standardized technique or design pattern" as A standardized technique or design pattern that is either:

• recommended in a wcag technique (techniques can be submitted by any other standard and just approved by wcag) or
• by the user platform
• or in a W3C note

My concern, taking the first and third, is that this would essentially be making W3C notes and WCAG techniques, which are informative, normative references (if the author chooses the "standardized technique" path to satisfy the SC). It also means that if WCAG techniques or W3C notes are not constantly kept up to date, there may well be techniques/patterns that become fairly ubiquitous and standardised, but are essentially made non-conformant by the fact that nobody's updated the techniques/notes yet to reflect that.

For "user platform", as the platform here is "the web" (rather than, say, iOS/Android/Windows), I'm not quite sure what's meant. Do you envisage authors having to browser-sniff/detect what OS the user's UA is running on, and then switch to whatever OS conventions there may be?

[lseeman]

I think the SC is normative in saying it needs to conform to design patterns techniques. We need to be a bit out the box here and techniques will need to be up to date as much as possible. However as many COGA user groups have difficulty learning and/or remembering new design patterns, we do not need to be fast changing. But maybe the following wording is clearer?

A standardized technique or design pattern that is either: A standard recommended in a wcag technique (techniques can be submitted by any other standard and just approved by wcag) or by the user platform (for native content and apps) The second bullet means we do not need to keep on top of every operating system.

However back to the user need, people need to learn the design pattern of their operating system, but when an uncommon design pattern from one operating system is used on a different operating system it can not be used by many coga users.

All the best

Lisa Seeman

LinkedIn, Twitter

---- On Thu, 09 Feb 2017 10:57:25 +0200 Patrick H. Lauke<notifications@github.com> wrote ----

We can define "A standardized technique or design pattern" as A standardized technique or design pattern that is either: recommended in a wcag technique (techniques can be submitted by any other standard and just approved by wcag) or by the user platform or in a W3C note My concern, taking the first and third, is that this would essentially be making W3C notes and WCAG techniques, which are informative, normative references (if the author chooses the "standardized technique" path to satisfy the SC). It also means that if WCAG techniques or W3C notes are not constantly kept up to date, there may well be techniques/patterns that become fairly ubiquitous and standardised, but are essentially made non-conformant by the fact that nobody's updated the techniques/notes yet to reflect that. For "user platform", as the platform here is "the web" (rather than, say, iOS/Android/Windows), I'm not quite sure what's meant. Do you envisage authors having to browser-sniff/detect what OS the user's UA is running on, and then switch to whatever OS conventions there may be? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[patrickhlauke]

I think the SC is normative in saying it needs to conform to design patterns techniques.

Yes. But if you then define these techniques as only including wcag techniques/notes (and platform conventions, but more on that below), you're essentially making those techniques/notes also normative, as they're listed as the only ones that satisfy the normative requirement, unless I'm missing something.

However as many COGA user groups have difficulty learning and/or remembering new design patterns, we do not need to be fast changing.

While I understand that from a user's point of view, in essence this means that the web at large (who wants to conform to this SC) is not allowed to innovate - or only allowed as fast as WCAG techniques/notes are updated.

A standardized technique or design pattern that is either: A standard recommended in a wcag technique (techniques can be submitted by any other standard and just approved by wcag) or by the user platform (for native content and apps)

WCAG is not directly concerned with native content and apps though. So that bullet, for web content, would boil down to just recommended WCAG techniques being recognised as "standardized techniques", which is very limiting and again would require techniques to be constantly kept up to date (which I know is one of the ideas of having techniques, but if WCAG 2.0 is anything to go by...it won't happen all that often)

[lseeman]

@patrickhlauke can we have a call to try and resolve this concern? are u on skype? Do you have a suggested direction that is more conventional for WCAG ? Unfortunately I think we may need to be a bit out the box to meet these user needs.

[patrickhlauke]

@lseeman sorry been in meetings most of the day. have to admit that no, i have no easy solution/approach to resolve this concern...it's quite fundamental though, because if the normative part of the SC demands the use of "standardised" patterns/conventions, and there are no authoritative standards on this (as it's an area of usability, arguably), it won't be actionable by authors nor testable. and setting up W3C/WCAG as the arbiters/keeper of such a standard feels fundamentally wrong, as i'd argue it's not the purpose of W3C/WCAG to mandate what is and isn't a "standard" in terms of visual design/operation/usability.

the only way out of this that i can see is to soften the language, and to talk about "common" (rather than standardised) patterns and to make the list of such patterns non-exclusive ("including, but not limited to, ...") - and then leave it up to the judgement of the designer/auditor to determine what is and isn't common. risk here is that this makes it far less unambiguously testable, which may be ok for AAA or even AA, but probably not A.

[lseeman]

why is this open now?

[lseeman]

@patrickhlauke I do not think "it feels wrong" is a good reason to exclude people. We have limited the scope and enabled it to be achieved via personalization. SO we are not limiting the auther

[awkawk]

Updated the issue description to reflect the FPWD text and reopening issue.