LiveWhale is built with accessibility in mind.

We work with the following two specifications to ensure compliance of both our front-end interfaces as well as the back-end authoring tools.

• WCAG 2.1 AA
• Section 508

Note: Public-facing front end website and calendar code can be modified by customers after installation; our front end conformance report is based on the unmodified “out of the box” version delivered to new customers. If you elect to customize the theming of your site or calendar, you may be responsible for making sure your own custom theming/components are fully accessible. Let us know if you’d like our help making custom code accessible.

Testing the Accessibility of Your Site

We recommend the following resources for testing the accessibility of your site pages and content:

• W3C Web Accessibility Initiative is a great platform that includes resources for testers, developers, and content writers.
• Deque University offers many resources to learn more about accessibility.
• Several LiveWhale schools use platforms like SiteImprove to crawl their sites and organize the results of accessibility sacans.
• The WAVE browser plugin for Chrome can be used to scan individual pages for errors and warnings. (After running WAVE, it’s handy to go into Details and un-check “Features,” “Structural Elements,” and “ARIA” so the only remaining flags are “Errors” and “Alerts.”)

If you have a testing resource you’ve found useful, please reach out and let us know so we can include it on this list.

Accessibility Features in LiveWhale

For a more detailed breakdown of accessibility in LiveWhale, feel free to reach out to support and ask about our current Accessibility Conformance Report (ACR). We update the ACR annually, usually during the summer months. Here are a few highlights:

Keyboard navigability

• All LiveWhale interfaces have been tested for keyboard use, including tab-order and visual focus.

• All keyboard interactivity follows standard practices as indicated by WAI-ARIA Authoring Practices, except in special cases (WYSIWYG text editors, or the calendar “mini-cal” date picker) in which case instruction text has been provided.

  LiveWhale Calendar: all interfaces are compliant
  LiveWhale Storyteller: all interfaces are compliant
  LiveWhale CMS: the drag-and-drop navigation and photo gallery editors are not currently compliant (remediating this is on the product roadmap)

Screen reader navigability

• We test LiveWhale using VoiceOver for Mac and JAWS for Windows, and provide headers/landmarks, aria labels and roles, and other assistive text to screen readers browsing the user interfaces.

Form fields and labels

• All forms are clearly labeled with visual and/or screen-reader-only labels.
• Date pickers: the front-end date browser (the “mini cal” on the calendar) is screen-reader and keyboard accessible and instruction text is provided; use the Arrow keys and Enter to navigate. On the back-end editor forms, mouse users can use the popup datepicker, and the required date formatting (e.g. mm/dd/yyyy ) has been provided as a label and placeholder for keyboard and screen reader users.

Color and contrast

• LiveWhale interfaces only use colors with sufficient contrast per WCAG 2.0 AA.
• No interfaces use only color as a distinguishing factor (for example, the icon for “starring” or “unstarring” changes both its color and from outlined to solid when checked).

Image ALT text

• When users add or place images, we require captions which are then used as ALT text.
• We do grant editors the ability to bypass captions when adding decorative images.

User prompts for accessibility

• In LiveWhale CMS, we bundle out-of-the-box with a built-in page accessibility checker, which will indicate at the top of every page the current accessibility score of the page, and opening the Accessibility panel will provide a more detailed report of suggested areas for improvement.

User permissions for accessibility

• In LiveWhale CMS, you may want to prevent users from uploading PDFs until they have undergone training about creating accessible PDFs. For this reason, “Upload files” is a separate permission that can be granted/revoked on a per-user basis.

Anything we missed? We welcome feedback on the accessibility of LiveWhale, if you find a bug or have a question, please don’t hesitate to reach out.

Reporting Accessibility Bugs in LiveWhale

You can report accessibility issues to the team using the support forum. Accessibility bugs get added to our roadmap at no cost to you, provided they meet these criteria:

• We can reproduce the problem on our test sites (e.g., it’s a problem with core code and not impacted by client-specific code)
• We agree it is a WCAG 2.1 violation

Issues meeting those criteria we will add to the roadmap/ACR for remediation in a future LiveWhale release. Otherwise, issues we don’t think are WCAG violations or may be impacted by client code we can offer advice or thoughts on remediating. For help remediating accessibility issues in client-specific code, you can use this form.

Developer Resources for Accessibility

If you are a developer working on a LiveWhale site, building new themes, custom functionality, or simply curious to learn more about our approach to accessibility, this section is for you.

Tools

The tools we’ve found most useful for accessibility testing are:

• The ARC Toolkit plugin for Chrome. This adds a tab to your Web Inspector that allows you to run a suite of tests, and then for each result you can click and the panel will show you exactly the markup that triggered it.
• The WAVE plugin for Chrome. This is a bit clunkier than ARC, and it catches a lot of the same things, but it’s used by many schools (and many government agencies) so it’s a good one to check as well.
  • After running WAVE, it’s handy to go into Details and un-check “Features,” “Structural Elements,” and “ARIA” so the only remaining flags are “Errors” and “Alerts.”
• Enabling VoiceOver for Mac for testing the screen reader experience.
• Having an installation of Windows and JAWS setup for testing is great, as that’s a very popular screen reader as well, but VoiceOver is on every Mac and is way better than nothing.
• Lighthouse accessibility and performance testing for Chrome DevTools.

What and How to Test

Keyboard Navigability

1. Using tab key: Can all content be tabbed to? Is the visual focus clear and stark?
2. Check the tab order with ARC Toolkit: Does the tab order make sense? Will a sighted user reach the next item visually when they tab?
3. Interact with all interactive elements
4. Buttons work with spacebar and enter
5. Escape lets a user out of a modal or expanded area, and focus goes to the proper place

The WAI-ARIA Authoring Practices are very extensive, but have good examples of best-practices when it comes to patterns like drop-downs, navigations, modals, popups, etc.

Screen Reader Navigability

Navigate the site using VoiceOver. Under Settings > VoiceOver on your computer, you can set your VoiceOver modifier key (indicated as “VO” below; I use Caps Lock), and the most useful keyboard shortcuts I’ve found are:

• Cmd + F5 = Turn Voiceover On/Off
• VO + A = Start reading from current point
• VO + Right Arrow = Move to next item
• VO + Left Arrow = Move to previous item
• VO + U = Open the “Rotor” tool to view headings/forms/etc.
• Tab = move to next interactive/focusable item

Note that it’s good to test both cases: just using “Tab” like you would as a keyboard user, and using the Virtual Cursor (VO+Left, VO+Right) to navigate and read even non-focusable elements.

Color Contrast

Both the ARC Toolkit and WAVE will flag contrast errors for you. In cases of background images or transparent backgrounds, you may need to manually plug hex codes in for testing. (WAVE has a good tester in the “Contrast” tab.)

200% Zoom

Use ARC Toolkit and select “Check page reflow (WCAG 2.1)” which resizes your window and zooms to 400%. Manually reduce zoom to 200%.

• Check for overlapping content.
• Ensure there is no horizontal scroll bar.
• Ensure there are not multiple vertical scroll bars.
• Check all expandables, hamburger menus, and interactive content.

Videos and Audio

• Do videos or audio include closed-captioning or text alternatives?

Other ARC Toolkit Tests

• Headings and Landmarks, which includes “bypass” methods like skip links.
• Images, to check for ALT text, etc.
• Links checks for empty links or other link issues

Strategies for Custom Code

Coding for Screen Readers

• Use class="lw_sr_only" to indicate a design element is for screen readers only (hidden from sighted visitors)
• Use role="presentation" and/or aria-hidden="true" to hide an element from screen readers

Coding for Keyboards

• Managing Focus
  • Use tabindex="0" to add an element to the normal tab order (e.g., if you’re using a span as a button, it should include role=”button” and tabindex=”0”)
  • Use tabindex="-1" to make an element tabbable (if it’s the target of an anchor link, for instance, or if you might use JS to focus it at some point)
  • Don’t use tabindex of greater than zero to try to manually set tab order; with elements that might appear anywhere on a page, or might be edited later, it’s a recipe for things breaking later on.
• Include skip links (at least one for “Skip to Main Content”) at the top of the page; use CSS to make this element only appear when focused. Using the class="lw_skip_link" does this for you, though it’s not styled out of the box and you could design a prettier one if you wanted.
• Following the WAI-ARIA Authoring Practices often includes coding custom keyboard interactions (for Enter, Arrow Keys, and Escape) that might not be what a browser does natively. If it helps, here are some blocks we’ve used in the past to accomplish this.