References
Cross-references
Infusion identifies the main content files in your documentation as patterns, and they’re kept in the content → patterns folder. It’s easy to cross-reference patterns 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.
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)
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.