skip to content

#
References

## Cross-references

Infusion provides an easy mechanism to cross-reference patterns, by title, using the `pattern` shortcode. For example, I can reference the
Notes & warnings pattern. Here’s what the markdown looks like, including the shortcode:

    I can reference the {{% pattern "Notes & warnings" %}} pattern here.

This saves you having to worry about pathing and decorates the generated link with a bookmark icon, identifying the link as a pattern reference visually.

The title argument you supply to the shortcode must be exactly the same as the referenced pattern’s `title` metadata value and is case sensitive.

## WCAG References

WCAG 2.0 is the de facto standard for accessible interfaces. When writing about inclusive design patterns, sometimes you’ll want to refer to WCAG to highlight which success criteria the pattern meets.

Instead of having to copy and paste content and links to WCAG, Infusion provides a shortcode mechanism that lets you simply list the success criteria by number:

    {{% wcag include="1.2.1, 1.3.1, 4.1.2" %}}

This generates a list of references that includes the names of each criterion and links to them directly. Like this:

- 2.1.1 Keyboard (level A)
- 4.1.2 Name, Role, Value (level A)

You don’t have to leave spaces after the comma separators. They are optional.

### Full descriptions

Sometimes, you’ll want to include the full descriptions of the success criteria inline. This is possible by setting `descriptions` to `true`:

    {{% wcag include="1.3.1, 4.1.2" descriptions="true" %}}

Here’s the more verbose output:

- 2.1.1 Keyboard (level A): All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints
- 4.1.2 Name, Role, Value (level A): For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies.

## Inclusive Design Principle references

Some inclusive design concepts are not reducible to success or fail criteria. This is why The Paciello Group wrote the Inclusive Design Principles. These can be listed by name.

    {{% principles include="Add value, Be consistent" descriptions="true" %}}

Here’s the output with `descriptions="true"`:

- Be consistent : Use familiar conventions and apply them consistently.

  Familiar interfaces borrow from well-established patterns. These should be used consistently within the interface to reinforce their meaning and purpose. This should be applied to functionality, behavior, editorial, and presentation. You should say the same things in the same way and users should be able to do the same things in the same way.

- Add value : Consider the value of features and how they improve the experience for different users.

  Features should add value to the user experience by providing efficient and diverse ways to find and interact with content. Consider device features such as voice, geolocation, camera and vibration API's, and how integration with connected devices or a second screen could provide choice.