+
+ + Documentation for the Cupper documentation builder, built with Cupper itself. + + + Print version + + +
+ +
+
+ + Documentation for the Cupper documentation builder, built with Cupper itself. + + + Print version + + +
+ +
+
+ + Documentation for the Cupper documentation builder, built with Cupper itself. + + + Print version + + +
+ +
+
+ + Documentation for the Cupper documentation builder, built with Cupper itself. + + + Print version + + +
+ +
+
+ + Documentation for the Cupper documentation builder, built with Cupper itself. + + + Print version + + +
+ +
+
+ + Documentation for the Cupper documentation builder, built with Cupper itself. + + + Print version + + +
+ +
+
+ + Documentation for the Cupper documentation builder, built with Cupper itself. + + + Print version + + +
+ +
+
+ + Documentation for the Cupper documentation builder, built with Cupper itself. + + + Print version + + +
+ +
+
+ + Documentation for the Cupper documentation builder, built with Cupper itself. + + + Print version + + +
+ +When you’re an inclusive designer, it’s pertinent to do some testing. Following specs is one thing, but you need to verify that your component works okay for users.
+ +Cupper provided a tested shortcode that lets you show which browsers and assistive technologies you’ve tried your design out in. Here’s an example. Note the commas and “+” signs.
+{{% tested using="Firefox + JAWS, Chrome, Safari iOS + Voiceover, Edge" %}}
+This outputs:
+ + + + +| + + Tested using + | + +
+
+
+
+
+
+ 
+ Firefox
+ with JAWS
+
+ |
+
+
+
+
+
+ 
+ Chrome
+
+ |
+
+
+
+
+
+
+
+ 
+ Safari iOS
+ with Voiceover
+
+ |
+
+
+
+
+
+ 
+ Edge
+
+ |
+
+
|---|
The value for the using attribute follows a specific format: each testing setup is separated by a comma (with a space if you like, but it’s not mandatory). If you want to add an assistive technology (or any other “add on”) this needs to follow a “+”. This additional part can be anything, like “A VR headset I borrowed”, but there are only a few browser terms available. These are case sensitive, so you need to write them as below:
Obviously, this is not a comprehensive list and more may be added over time. But it covers most of the main browsers for pairing with other software — at least for testing purposes.
+ +
+
+ + Documentation for the Cupper documentation builder, built with Cupper itself. + + + Print version + + +
+ +
+
+ + Documentation for the Cupper documentation builder, built with Cupper itself. + + + Print version + + +
+ +
+
+ + Documentation for the Cupper documentation builder, built with Cupper itself. + + + Print version + + +
+ +Cupper is built using the static site engine, Hugo, and NPM. The codebase is available to download on Github. Let’s get everything installed step-by-step.
+ +First you need to install Hugo globally.
+ +If you are a Mac user and have Homebrew on your system, installing Hugo is simple:
+ +brew install hugoAlternatively, you can manually install Hugo from a package. You can verify the installation was successful by typing:
+ +hugo versionInstalling on Windows is a little more involved than on OSX. The authors of Hugo provide a guide with instructions for technical and less technical users.
+ +It’s also best you install a Windows Subsystem for running Linux, and therefore bash (Cupper incorporates some bash commands in its scripts). Microsoft offer a complete guide.
+ +It is likely you already have Node and NPM installed on your system. If so, you can skip this step. Otherwise, refer to NPM’s own guide, which includes a video tutorial.
+ +Cupper is hosted on Github. To start using it, you’ll need to get the files from there. If you are comfortable with the command line, just fork the github.com/ThePacielloGroup/cupper repository, then do a git clone to your local system. Replace [your username] in the following:
git clone https://github.com/[your username]/cupper.gitIf the command line is not your thing, use Github’s web interface to fork github.com/ThePacielloGroup/cupper and choose Open in Desktop from Clone or download (see figure 1, below).
+ + +
While you’re in the Github interface, you might as well set up the publishing source for the live site. Choose the Master branch/docs option under Settings → Github Pages → Source. See Serving for more details.
+ +Once you have your local copy of the files, move to the root of that folder and in your terminal run an npm installation:
+ +npm installNow it’s time to consult the Setup pattern.
+ +
+
+ + Documentation for the Cupper documentation builder, built with Cupper itself. + + + Print version + + +
+ +From time to time, you’ll be wanting to include images illustrating the documented pattern in hand. Images live in the static folder, which is a sibling of the /content folder you’ll be mostly working in.
The path to the /images folder should begin with a forward slash, so include that when referencing images in your markdown.
+Sometimes you will want to include a caption with your illustration. This is what the <figure> and <figcaption> elements are for. However, Cupper doesn’t ask you to code all that manually. A special shortcode is provided, which takes a caption parameter. Note that the image markdown is provided between the opening and closing shortcode tags, and that you can use markdown syntax in the caption value.
+{{% figure caption="A design system that uses a bad code example as a **single source of truth** only serves to proliferate bad code." %}}
+
+{{% /figure %}}
+This will output the following. Note the automatically incremented Figure number.
+ + +
The generated markup includes special provisions for assistive technology support:
+ +<figure role="group" aria-describedby="caption-5fbafefe946c724e7a5d3d2d447a8684">
+ <p><img src="http://localhost:1313/images/bad_design_system.png" alt="Diagram of a design pattern represented by a turd emoji begetting three bad implementations"></p>
+ <figcaption id="caption-5fbafefe946c724e7a5d3d2d447a8684">
+ A design system that uses a bad code example as a <strong>single source of truth</strong> only serves to proliferate bad code.
+ </figcaption>
+</figure>
++ Documentation for the Cupper documentation builder, built with Cupper itself. + + + Print version + + +
+ +
+
+ + Documentation for the Cupper documentation builder, built with Cupper itself. + + + Print version + + +
+ +
+
+ + Documentation for the Cupper documentation builder, built with Cupper itself. + + + Print version + + +
+ +
+
+ + Documentation for the Cupper documentation builder, built with Cupper itself. + + + Print version + + +
+ +While you’re creating content for your project, you’ll probably want to see what the finished product looks like. Fortunately, Cupper is easy to serve locally using the serve command:
npm run serveThis will serve your working project from localhost:1313. Whenever you make changes to your files, the site will automatically rebuild. No need to refresh the web page!
Cupper creates a /docs folder containing the latest version of your site whenever you do an npm run build or a git commit. So long as you forked the Cupper repository when making your own version (see Setup), whenever you push to master, you will also be updating the site found at your Github Pages URL.
This URL will be in the following format:
+ +[your user name].github.io/[your library repo name]
+You’ll also need to add this value to your config.toml file as the baseURL. For Cupper’s own documentation it looks like the following. Just overwrite it.
baseURL = "https://thepaciellogroup.github.io/cupper/"
+You will find the docs folder is not automatically setup as the publishing source, even when forking the repo. In which case, you must set it under Settings → Github Pages → Source in the web interface.
+
+ + Documentation for the Cupper documentation builder, built with Cupper itself. + + + Print version + + +
+ +By now, you should have followed the Installation instructions. You should have Hugo and Node installed, and a local copy of a forked version of Cupper. You should also have run npm install in the root of that codebase.
Before you can start writing documentation, there are a few things still to do in order to get set up. At the moment, your version of Cupper is a facsimile of the original, containing all the content you’re reading right now. We want to delete that content and replace it with some starter content. There’s a simple clean command for this.
npm run cleanThis will leave your content folder with just an _index.md file and a patterns folder containing a single demonstration pattern file. Individual content pages in Cupper are referred to as “patterns” — think pattern libraries). Find out more about these in Project structure.
You’ll also want to name your project and configure one or two other things in the config.toml file that’s found at the root of your project. Here’s how that file looks:
+languageCode = "en-us"
+title = "Cupper"
+baseURL = "https://thepaciellogroup.github.io/cupper/"
+theme = "cupper"
+
+[params]
+ description = "Documentation for the **Cupper** documentation builder. This documentation is constructed using the builder itself."
+ codePenUser = "Heydon"
+title is simply Cupper :-)Cupper projects work as progressive web applications, meaning users can save them to their home screen and read them offline. The web app manifest, found at the root of the static folder, defines names and icons for the app. You’ll probably want to open /static/manifest.json and personalize the name and short_name values.
{
+ "name": "Cupper Documentation Builder",
+ "short_name": "Cupper Docs",
+ "icons": [
+ {...
+
short_name displayed, available from the homescreen of a Samsung/Android phone.
+ In the images/static folder, you’ll find a logo.svg file. Replace this file with your own company or project logo, under the same file name. Currently, only SVG is supported this easily because SVG is the superior format for logos. However, if you must use a different format, you can open up the themes/cupper/layouts/_default/baseof.html file and edit the image reference:
<a class="logo" href="/" aria-label="{{ .Site.Title }} pattern library home page">
+ <img src="{{ "images/logo.svg" | absURL }}" alt="">
+</a>
+Now that your logo is in place, everything should be ready. Where next? You can learn about Project structure to help you get writing, or find out how to serve the site locally and on Github Pages in Serving.
+ +
+
+ + Documentation for the Cupper documentation builder, built with Cupper itself. + + + Print version + + +
+ +
+
+ + Documentation for the Cupper documentation builder, built with Cupper itself. + + + Print version + + +
+ +
+
+ + Documentation for the Cupper documentation builder, built with Cupper itself. + + + Print version + + +
+ +
+
+ + Documentation for the Cupper documentation builder, built with Cupper itself. + + + Print version + + +
+ +
+
+ + Documentation for the Cupper documentation builder, built with Cupper itself. + + + Print version + + +
+ +
+
+ + Documentation for the Cupper documentation builder, built with Cupper itself. + + + Print version + + +
+ +
+
+ + Documentation for the Cupper documentation builder, built with Cupper itself. + + + Print version + + +
+ +
+
+ + Documentation for the Cupper documentation builder, built with Cupper itself. + + + Print version + + +
+ +
+
+ + Documentation for the Cupper documentation builder, built with Cupper itself. + + + Print version + + +
+ +
+
+ + Documentation for the Cupper documentation builder, built with Cupper itself. + + +
+ ++ + Table of contents + +
+ +Cupper is built using the static site engine, Hugo, and NPM. The codebase is available to download on Github. Let’s get everything installed step-by-step.
+ +First you need to install Hugo globally.
+ +If you are a Mac user and have Homebrew on your system, installing Hugo is simple:
+ +brew install hugoAlternatively, you can manually install Hugo from a package. You can verify the installation was successful by typing:
+ +hugo versionInstalling on Windows is a little more involved than on OSX. The authors of Hugo provide a guide with instructions for technical and less technical users.
+ +It’s also best you install a Windows Subsystem for running Linux, and therefore bash (Cupper incorporates some bash commands in its scripts). Microsoft offer a complete guide.
+ +It is likely you already have Node and NPM installed on your system. If so, you can skip this step. Otherwise, refer to NPM’s own guide, which includes a video tutorial.
+ +Cupper is hosted on Github. To start using it, you’ll need to get the files from there. If you are comfortable with the command line, just fork the github.com/ThePacielloGroup/cupper repository, then do a git clone to your local system. Replace [your username] in the following:
git clone https://github.com/[your username]/cupper.gitIf the command line is not your thing, use Github’s web interface to fork github.com/ThePacielloGroup/cupper and choose Open in Desktop from Clone or download (see figure 1, below).
+ + +
While you’re in the Github interface, you might as well set up the publishing source for the live site. Choose the Master branch/docs option under Settings → Github Pages → Source. See Serving for more details.
+ +Once you have your local copy of the files, move to the root of that folder and in your terminal run an npm installation:
+ +npm installNow it’s time to consult the Setup pattern.
+ +By now, you should have followed the Installation instructions. You should have Hugo and Node installed, and a local copy of a forked version of Cupper. You should also have run npm install in the root of that codebase.
Before you can start writing documentation, there are a few things still to do in order to get set up. At the moment, your version of Cupper is a facsimile of the original, containing all the content you’re reading right now. We want to delete that content and replace it with some starter content. There’s a simple clean command for this.
npm run cleanThis will leave your content folder with just an _index.md file and a patterns folder containing a single demonstration pattern file. Individual content pages in Cupper are referred to as “patterns” — think pattern libraries). Find out more about these in Project structure.
You’ll also want to name your project and configure one or two other things in the config.toml file that’s found at the root of your project. Here’s how that file looks:
+languageCode = "en-us"
+title = "Cupper"
+baseURL = "https://thepaciellogroup.github.io/cupper/"
+theme = "cupper"
+
+[params]
+ description = "Documentation for the **Cupper** documentation builder. This documentation is constructed using the builder itself."
+ codePenUser = "Heydon"
+title is simply Cupper :-)Cupper projects work as progressive web applications, meaning users can save them to their home screen and read them offline. The web app manifest, found at the root of the static folder, defines names and icons for the app. You’ll probably want to open /static/manifest.json and personalize the name and short_name values.
{
+ "name": "Cupper Documentation Builder",
+ "short_name": "Cupper Docs",
+ "icons": [
+ {...
+
short_name displayed, available from the homescreen of a Samsung/Android phone.
+ In the images/static folder, you’ll find a logo.svg file. Replace this file with your own company or project logo, under the same file name. Currently, only SVG is supported this easily because SVG is the superior format for logos. However, if you must use a different format, you can open up the themes/cupper/layouts/_default/baseof.html file and edit the image reference:
<a class="logo" href="/" aria-label="{{ .Site.Title }} pattern library home page">
+ <img src="{{ "images/logo.svg" | absURL }}" alt="">
+</a>
+Now that your logo is in place, everything should be ready. Where next? You can learn about Project structure to help you get writing, or find out how to serve the site locally and on Github Pages in Serving.
+ +While you’re creating content for your project, you’ll probably want to see what the finished product looks like. Fortunately, Cupper is easy to serve locally using the serve command:
npm run serveThis will serve your working project from localhost:1313. Whenever you make changes to your files, the site will automatically rebuild. No need to refresh the web page!
Cupper creates a /docs folder containing the latest version of your site whenever you do an npm run build or a git commit. So long as you forked the Cupper repository when making your own version (see Setup), whenever you push to master, you will also be updating the site found at your Github Pages URL.
This URL will be in the following format:
+ +[your user name].github.io/[your library repo name]
+You’ll also need to add this value to your config.toml file as the baseURL. For Cupper’s own documentation it looks like the following. Just overwrite it.
baseURL = "https://thepaciellogroup.github.io/cupper/"
+You will find the docs folder is not automatically setup as the publishing source, even when forking the repo. In which case, you must set it under Settings → Github Pages → Source in the web interface.
Cupper’s output site includes a one-page Print version of the generated library, available at /print-version. So, if your library base URL is https://yourName.github.io/your-library, you can print the whole library — to PDF if wanted — from the following address:
https://yourName.github.io/your-library/print-version
++
+ +The core of Cupper’s functionality is in its Hugo theme, also called Cupper. This is found in the theme folder.
+ +Do not “hack the core”. If you have any issues with Cupper, please report them to the Cupper Github repository and they will be dealt with ASAP.
+ +Cupper is undergoing constant development, so keep an eye out for new releases. To update to a new version of Cupper, simply run the update command from inside your local project folder.
npm run updateThis will save a timestamped backup of the current version, and download the latest version. Your theme folder will now look something like the following.
+ +If you experience breaking changes and are having trouble fixing them, you can rename the old folder and revert to using it. In the meantime, you can submit an issue with the “help” tag describing your problem.
+ + + + +Before you can set about making documentation, you need to know where everything goes. The simplest folder structure looks like this:
+ +You may have noticed that this site’s navigation is divided partly into subsections, with labels like “Writing”. Cupper (or, rather, Hugo) allows you to create such subsections by simply nesting folders under the /patterns folder. In the following example, I have a subsection about different types of “popup” pattern.
Subfolders like /popups must each have an _index.md file. This file doesn’t need any content except the TOML metadata defining the title (name) of that subsection:
+++
+title = "Popup windows"
++++
+This title is what labels the subsection in the navigation, not the folder name (/popups, in this case). For each subfolder you create, you must also create one of these _index.md files. The /patterns folder itself does not need one, however.
Now that you know where to put everything, it’s time to talk about how to actually write individual patterns. Don’t worry, it’s pretty straightforward. Turn to Markdown & metadata.
+ +In Cupper everything is documented using markdown, as a “pattern”. To create a new pattern file, just add a file with the .md extension to the content/patterns folder. It’s recommended you use “kebab case” to name the file (words separated by hyphens). For example, a pattern with the title “Menu button” should probably have the filename menu-button. Then you get a nice clean URL: username.github.io/your-library/patterns/menu-button.
If you’re not familiar with writing markdown, there are a number of tutorials available. One of the best is Mastering Markdown offered by Github. There’s also a nice cheatsheet here.
+ +Like many static site generators, Hugo lets you add metadata to its markdown files. Hugo’s brand of metadata is called TOML (although YAML is also accepted). The only thing you have to put in the TOML is a title — like this:
+++
+title = "Menu button"
++++
+If you like, you can also tag the pattern so that it turns up in lists of similar content. You add tags in an array format. Note that all the TOML data is found at the top of the markdown file, between the +++ lines.
+++
+title = "Menu button"
+tags = ["interactive", "popup", "javascript"]
++++
+This will create links to pages listing content tagged with the same terms using the URL schema /tag/[tag name]. Some example tags links are provided for this page, which you can see listed under the main heading.
By default, patterns are listed alphabetically in the navigation. However, sometimes you might like to change the order around. This is possible by adding a weight parameter. To make my menu button pattern appear at the top of its subsection, I would give it a weight of 1:
+++
+title = "Menu button"
+tags = ["interactive", "popup", "javascript"]
+weight = 1
++++
+In some cases, where there is a lot of content, it’s helpful to collapse certain sections. That way, readers get an overview of what’s in the content and can choose where to focus in. Cupper provides a shortcode method for creating expandable sections which generates accessible markup using aria-expanded.
The expandable shortcode takes three parameters:
level="2" for an <h2>) that will contain the label. If you omit a level parameter, no heading is used; it’s just a button.Here’s what the code might look like for a simple expandable section containing markdown:
+ +
+{{% expandable label="A section of dummy text" level="2" %}}
+Here is some markdown including [a link](https://twitter.com/heydonworks). Donec erat est, feugiat a est sed, aliquet pharetra ipsum. Vivamus in arcu leo. Praesent feugiat, purus a molestie ultrices, libero massa iaculis ante, sit amet accumsan leo eros vel ligula.
+{{% /expandable %}}
+Let’s look at what that outputs:
+ + + + +Successive collapsible sections fit snugly together. The second of the following two has open="true".
Unfortunately, it is not currently possible to include shortcodes inside other shortcodes, using the “%” notation (which is designated for markdown content). If you use the angle brackets notation (illustrated below) it is possible, but markdown will no longer be permitted. You will have to code HTML inside such a section manually.
+{{<expandable label="A section of dummy text" level="2">}}
+<p>Here is a pattern reference shortcode: {{% pattern "Writing inline demos" %}}.</p>
+{{</expandable>}}
+Cupper acknowledges that simple markdown is limiting when it comes to writing compelling documentation, so it provides a number of “shortcodes”. Shortcodes offer a simple syntax for including rich content. For example, Cupper provides shortcodes for including notes and warnings.
+ +You may wish to pick out some content in your pattern’s documentation as a note — an aside to the main thrust of the pattern’s description. This is possible using the following syntax:
+ +
+{{% note %}}
+This is a note! It's something the reader may like to know about but is supplementary to the main content. Use notes when something may be interesting but not critical.
+{{% /note %}}
+Notes render like this:
+ + + + +Warnings are like notes, but with more urgency.
+ +
+{{% warning %}}
+This is a warning! It's about something the reader should be careful to do or to avoid doing. Use warnings when something could go wrong.
+{{% /warning %}}
+Warnings render like this:
+ + + + +Cupper 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 2.0 is the de facto standard for accessible interfaces. When writing about inclusive interfaces, 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, Cupper 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:
+ + + + + +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:
+ + + + + +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":
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.
+ +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.
+ +A lot of the time, your larger documentation patterns will share some common techniques and utilities. For this reason, Cupper lets you save snippets of markdown in a snippets folder, alongside the main content folder.
+ +The example visually-hidden.md snippet describes the CSS needed to create content that is visually hidden but still available to screen readers. Since this is a technique/utility you are likely to use often, it’s nice to be able to just drop a snippet into your markdown content. The snippet shortcode lets you do exactly that:
+{{% snippet file="visually-hidden.md" %}}
+The visually-hidden utility class uses a set of special properties to hide content visually without making it unavailable to screen readers and other non-visual user agents. The class is defined like this:
.visually-hidden {
+ position: absolute !important;
+ clip: rect(1px, 1px, 1px, 1px) !important;
+ padding:0 !important;
+ border:0 !important;
+ height: 1px !important;
+ width: 1px !important;
+ overflow: hidden !important;
+}
+Use it sparingly since, in most cases, what is identified non-visually should also be presented visually. Bear in mind that not all screen reader users are blind users. + + +
Pattern pages in Cupper that have two or more subheadings (<h2>s) automatically get a table of contents: a list of links to the main subsections for the page. This feature is made accessible as a navigation region with the “Table of contents” label and uses an ordered list. The table of contents markup for the Setup page looks something like this:
<nav class="toc" aria-labelledby="toc-heading">
+ <h2 id="toc-heading">Table of contents</h2>
+ <ol>
+ <li>
+ <a href="#cleaning-the-content-folder">“Cleaning” the content folder</a>
+ </li>
+ <li>
+ <a href="#the-setup-command">The setup command</a>
+ </li>
+ <li>
+ <a href="#the-config-file">The config file</a>
+ </li>
+ <li>
+ <a href="#including-a-logo">Including a logo</a>
+ </li>
+ </ol>
+</nav>
+Tables of content are a neat way to break down the content of the page and give users a navigable overview. However, they may not be to your taste. Never fear, you can turn tables of content off by adding toc = false to the TOML metadata for your pattern:
+++
+title = "My page with a few headings"
+toc = false
++++
+From time to time, you’ll be wanting to include images illustrating the documented pattern in hand. Images live in the static folder, which is a sibling of the /content folder you’ll be mostly working in.
The path to the /images folder should begin with a forward slash, so include that when referencing images in your markdown.
+Sometimes you will want to include a caption with your illustration. This is what the <figure> and <figcaption> elements are for. However, Cupper doesn’t ask you to code all that manually. A special shortcode is provided, which takes a caption parameter. Note that the image markdown is provided between the opening and closing shortcode tags, and that you can use markdown syntax in the caption value.
+{{% figure caption="A design system that uses a bad code example as a **single source of truth** only serves to proliferate bad code." %}}
+
+{{% /figure %}}
+This will output the following. Note the automatically incremented Figure number.
+ + +
The generated markup includes special provisions for assistive technology support:
+ +<figure role="group" aria-describedby="caption-5fbafefe946c724e7a5d3d2d447a8684">
+ <p><img src="http://localhost:1313/images/bad_design_system.png" alt="Diagram of a design pattern represented by a turd emoji begetting three bad implementations"></p>
+ <figcaption id="caption-5fbafefe946c724e7a5d3d2d447a8684">
+ A design system that uses a bad code example as a <strong>single source of truth</strong> only serves to proliferate bad code.
+ </figcaption>
+</figure>
+Cupper has a lot of its own shortcodes, but you can still use Hugo’s built in shortcodes. These include a simple shortcode for including YouTube videos in your content. The shortcode takes just one parameter — the video’s id.
+{{<youtube w7Ft2ymGmfc>}}
+Markdown already supports code samples both inline (using single backticks like `some code here`) and in blocks. Cupper will syntax highlight HTML, CSS, and JavaScript if you provide the correct language in the formulation of the block.
+ +So, this…
+ +
+```html
+<button aria-pressed="false">toggle me</button>
+```
+… will result in this:
+ +<button aria-pressed="false">toggle me</button>
+Note that the syntax highlighting uses a greyscale theme. Cupper is careful not to use color as part of its own design, because these colors may clash with those of the design being illustrated and discussed.
+ + + + +Cupper offers the ability to highlight and annotate specific parts of your code examples using the code shortcode. Take an accessible dialog. You may wish to point out key attributes that make that dialog support assistive technologies:
+<div role="dialog" aria-labelledby="dialog-heading">
+ <button aria-label="close">x</button>
+ <h2 id="dialog-heading">Confirmation</h2>
+ <p>Press <strong>Okay</strong> to confirm or <strong>Cancel</strong></p>
+ <button>Okay</button>
+ <button>Cancel</button>
+</div>
+You mark out the highlighted areas using triple square brackets like so:
+ +
+{{<code>}}
+<div [[[role="dialog"]]] [[[aria-labelledby="dialog-heading"]]]>
+ <button [[[aria-label="close"]]]>x</button>
+ <h2 [[[id="dialog-heading"]]]>Confirmation</h2>
+ <p>Press Okay to confirm or Cancel</p>
+ <button>Okay</button>
+ <button>Cancel</button>
+</div>
+{{</code>}}
+Better still, if you include numbered="true", each highlight is enumerated so you can reference it directly in the ensuing text. If you follow the shortcode directly with an ordered list, the styles match:
+<div role="dialog" aria-labelledby="dialog-heading">
+ <button aria-label="close">x</button>
+ <h2 id="dialog-heading">Confirmation</h2>
+ <p>Press <strong>Okay</strong> to confirm or <strong>Cancel</strong></p>
+ <button>Okay</button>
+ <button>Cancel</button>
+</div>
+dialog ARIA rolearia-labelledby relationship attribute makes the element carrying the id it points to its labelaria-label to provide the text label “close”, overriding the text contentaria-labelledby attribute points to its idYou just include numbered="true" on the opening shortcode tag:
+{{<code numbered="true">}}
+<div [[[role="dialog"]]] [[[aria-labelledby="dialog-heading"]]]>
+ <button [[[aria-label="close"]]]>x</button>
+ <h2 [[[id="dialog-heading"]]]>Confirmation</h2>
+ <p>Press Okay to confirm or Cancel</p>
+ <button>Okay</button>
+ <button>Cancel</button>
+</div>
+{{</code>}}
+
+1. The dialog is only announced as a dialog if it takes the `dialog` ARIA role
+2. The `aria-labelledby` relationship attribute makes the element carrying the `id` it points to its label
+3. The close button uses `aria-label` to provide the text label "close", overriding the text content
+4. The heading is used as the dialog's label. The `aria-labelledby` attribute points to its `id`
+
+/* Enable scrolling by keyboard of code samples */
+(function () {
+ var codeBlocks = document.querySelectorAll('pre, .code-annotated');
+
+ Array.prototype.forEach.call(codeBlocks, function (block) {
+ if (block.querySelector('code')) {
+ block.setAttribute('role', 'region');
+ block.setAttribute('aria-label', 'code sample');
+ if (block.scrollWidth > block.clientWidth) {
+ block.setAttribute('tabindex', '0');
+ }
+ }
+ });
+}());
+region role announces the block as a regionaria-label describes the kind of content to be expected in the regionSometimes just pictures of the pattern you’re documenting aren’t enough. Interactive patterns benefit from live demos, so that readers can test their functionality.
+ +Cupper offers a couple of ways to do this. The first is by embedding CodePen demos into the content. The codePen shortcode takes just one argument: the codePen’s ID.
+{{% codePen VpVNKW %}}
+This will embed the identified codePen into the content wherever you placed the shortcode, with the result view showing by default:
+ + + + + + + + + +You can embed JS Bins just like CodePens, supplying a single id parameter.
+{{% jsBin juwowaq %}}
+However, you can also have finer control over which panes are displayed. Use two parameters: one for the id and another, show, listing the panes you want to include.
+{{% jsBin id="juwowaq" show="css,output" %}}
+The options for the show parameter are:
(Note that, under some circumstances, the html pane is added whether you select it or not.)
Cupper also supports the ability to write inline demos directly in markdown files. See Writing inline demos.
+ +There are some issues with Demo embedding, like the embeds not working offline. They also come with their own branding, which will clash with the pattern you’re trying to illustrate.
+ +Cupper offers another option: a special demo shortcode that allows you to write HTML, CSS, and JavaScript directly into the markdown file. The outputted demo is encapsulated using Shadow DOM, so you don’t have to worry about broken styles and global JS.
Here’s the example code for an inline demo of a toggle button:
+ +
+{{<demo>}}
+<button aria-pressed="false">Toggle Me</button>
+<style>
+button {
+ background: DarkCyan;
+ color: white;
+ border: 0;
+ font-size: 1.5rem;
+ padding: 0.5em 1em;
+ border-right: 5px solid #000;
+ border-bottom: 5px solid #000;
+}
+
+[aria-pressed="true"] {
+ border: 0;
+ border-top: 5px solid #000;
+ border-left: 5px solid #000;
+}
+</style>
+<script>
+var toggle = demo.querySelector('[aria-pressed]');
+
+toggle.addEventListener('click', (e) => {
+ let pressed = e.target.getAttribute('aria-pressed') === 'true';
+ e.target.setAttribute('aria-pressed', !pressed);
+});
+</script>
+{{</demo>}}
+Note the demo.querySelector on line 21. Cupper automatically provides demo, representing the root node of the demo. It’s like the document keyword but for a demo’s subtree.
Here’s a live demo of… the demo:
+ + +The “Launch in separate window” button takes the demo code and pushes it to a new browser window. This serves two purposes:
+ +It’s possible to give your demo a caption using an accessible <figure> and <figcaption> structure. All you need to do is supply a caption attribute. For example:
+{{<demo caption="A basic button element">}}
+<!-- demo code here -->
+{{</demo>}}
+Along with the standard figure shortcodes (described in Including images), demo figures are numbered automatically according to their order in the page. You can use markdown syntax in the caption text value.
Sometimes your component will be expected to appear in a context where the parent element has a background color. You can add a backgroundColor for your demo block using the backgroundColor attribute. Any valid CSS color value is acceptable:
+{{<demo backgroundColor="hsla(163, 100%, 50%, 0.43)">}}
+<!-- demo code here -->
+{{</demo>}}
+There’s no reason why your Cupper-powered pattern library has to be all about functionality. You can include style guide-like information such as color palettes too. The colors shortcode makes it easy to exhibit colors and their values together. Just supply a comma-separated list of CSS color values.
+{{% colors "#111111, #cccccc, #ffffff" %}}
+The result is a one row strip showing each color supplied in order. The colors for Cupper are greyscale:
+ + + +Your pattern documentation may need to include commands for installing packages or using CLIs. Cupper offers the cmd shortcode for making code blocks look like terminal commands.
Here’s how you write it:
+ +
+{{<cmd>}}
+npm run start
+{{</cmd>}}
+And here’s how it looks:
+ +npm run startRepresenting folder/file structures is simple and accessible in Cupper. Which is just as well, because some components may need to conform to a certain folder structure.
+ +The file tree is described using a markdown nested list structure:
+ +
+{{% fileTree %}}
+* Level 1 folder
+ * Level 2 file
+ * Level 2 folder
+ * Level 3 file
+ * Level 3 folder
+ * Level 4 file
+ * Level 3 folder
+ * Level 4 file
+ * Level 4 file
+ * Level 3 file
+ * Level 2 folder
+ * Level 3 file
+ * Level 3 file
+ * Level 3 file
+ * Level 2 file
+* Level 1 file
+{{% /fileTree %}}
+This is drawn in the following fashion, but preserves the underlying nested list structure for assistive technologies such as screen readers:
+ +When you’re an inclusive designer, it’s pertinent to do some testing. Following specs is one thing, but you need to verify that your component works okay for users.
+ +Cupper provided a tested shortcode that lets you show which browsers and assistive technologies you’ve tried your design out in. Here’s an example. Note the commas and “+” signs.
+{{% tested using="Firefox + JAWS, Chrome, Safari iOS + Voiceover, Edge" %}}
+This outputs:
+ + + + +| + + Tested using + | + +
+
+
+
+
+
+
+ Firefox
+ with JAWS
+
+ |
+
+
+
+
+
+
+ Chrome
+
+ |
+
+
+
+
+
+
+
+
+ Safari iOS
+ with Voiceover
+
+ |
+
+
+
+
+
+
+ Edge
+
+ |
+
+
|---|
The value for the using attribute follows a specific format: each testing setup is separated by a comma (with a space if you like, but it’s not mandatory). If you want to add an assistive technology (or any other “add on”) this needs to follow a “+”. This additional part can be anything, like “A VR headset I borrowed”, but there are only a few browser terms available. These are case sensitive, so you need to write them as below:
Obviously, this is not a comprehensive list and more may be added over time. But it covers most of the main browsers for pairing with other software — at least for testing purposes.
+ +
+
+ + Documentation for the Cupper documentation builder, built with Cupper itself. + + + Print version + + +
+ +
+
+ + Documentation for the Cupper documentation builder, built with Cupper itself. + + + Print version + + +
+ +