Implementation Map:
Localist for Higher Education
Scheduled Calls
The following calls are staples in the implementation process and are integral to your organization’s success with Localist.
| Host | Customer Success Manager | Implementation Specialist | Implementation Specialist |
| Who should attend? | Main point of contact (required) + second in command (optional) | Main point of contact (required) + key decision makers (tech/design or lead calendar admins – optional) | Main point of contact (required) + only those who also attended the Kickoff Call |
| What will be covered? | Org/dep insight, past event marketing/calendar experience, Localist goals and implementation resources. | High-level information about the platform in order for you to devise a game plan for launch. | Thorough platform review, suggestions and actionable feedback following best practices, promotion strategies and metrics to track. |
| What should you prepare? | Scope of Services questions & Year #1 goals | Browse your new platform & admin dash | Send support a list of remaining questions & double check your Implementation Tracker. |
Timelines
The following are recommended timelines for implementation. While the exact time dedicated to each task may vary, the order in which you implement the platform must follow the “Order of Events” as outlined below.
| Week 1 | Welcome Call + Kickoff Call | Welcome Call | Welcome Call | Welcome Call |
| Week 2 |
1. Classification > Events 2. Technical Setup |
Kickoff Call | Kickoff Call | Kickoff Call |
| Week 3 | Platform Review Call + Final Touches | Classification & Start Technical Setup | Classification & Start Technical Setup | Classification & Start Technical Setup |
| Week 4 | Launch | Complete Classification + Start Adding Events | … | … |
| Week 5 | Complete Event Transition + Technical Setup | Start Adding Events | … | |
| Week 6 | Platform Review Call | … | … | |
| Week 7 | Final Touches | Complete Technical Setup | Start Adding Events | |
| Week 8 | Launch | … | … | |
| Week 9 | Platform Review Call | … | ||
| Week 10 | Final Touches | … | ||
| Week 11 | … | Complete Technical Setup | ||
| Week 12 | Launch | … | ||
| Week 13 | … | |||
| Week 14 | Platform Review Call | |||
| Week 15 | Final Touches | |||
| Week 16 | Launch |
Order of Events
Implementation steps are split into two categories: Content and Technical. Each section has an order of steps, but the sections as a whole can (and should) be worked on in parallel.
| 1. Classification | 1. Brand Template Development |
| Filters | 2. Theme Editor Updates & Additions |
| Custom Fields | 3. CSS Customizations & Clean up |
| Places + Groups/Departments | |
| Tags & Keywords | Custom Domain + SSL |
| 2. Add Events | Single-sign On |
| Submission Form | |
| Feeds | Global Options |
| Bulk Add | |
| 3. Promotion | |
| Channels | |
| Widgets
– Custom Widget Templates |
|
| Featured & Sponsored |
Fast Track
In a time crunch? Below you’ll find each Implementation feature and task designated as “need to have” or “nice to have” when it comes to launching your platform in the fastest time with the least amount of work as possible.
That said, once your “need to haves” are checked off, you will need to continue to work on the “nice to haves” as once your platform is out in the wild, these features will still be absolutely essential to the overall long term success of your platform.
NEED to have for a launch
- Classifications: Setting up your Classifications is the first step to setting up your platform. This introductory guide covers the benefits of Landing Pages and a concise, user-centric Filter list.
- Setting up your Landing Pages for Places, Groups and Departments.
- Setting up your Filters to include our best practices.
- Homepage Widget: Widgets allow you to curate events based on already existing Classifications (Groups, Departments, Filters, Tags, Keywords) to display on an external site. Having a Widget on SOU’s homepage will drive traffic back to your new calendar!
- Promoting Events: Featured and Sponsored events are a great way to help promote your coolest and most unique events. Featuring an event puts it in the Featured Events Carousel at the top of your platform and Sponsoring an event gives it a boost in trending and different branding.
- User and Admin Permissions: Our permissions are non-hierarchical, so if you want an Admin to be able to do everything, they need all boxes checked.
- Custom Domain: Make sure to set up a CNAME to get a Custom Domain.
- Branding: You’re able to make changes to Fonts, Colors, and CSS to adopt your unique branding without your Brand Template.
NICE to have for launch
- Channels: Channels are a Promotion tool for short-term events or a topical theme. Events like Welcome Week, Graduation, Homecoming, or Athletics are great examples of channels.
- Widgets: Widgets allow you to curate events based on already existing classification (groups, filters, tags, keywords) to display on an external site.
- Custom Fields: Custom Fields allow you to collect any additional information that your organization needs.
- Custom Submission Form Guidelines: Provide instructions for your users when submitting events.
- Brand Template: This is your main tool for branding, and this guide will help you set it up.
- Theme Editor: This is our guide to using the Localist Theme Editor for any HTML changes you want to make to the design of the platform.
- SSO: We support CAS, LDAP/AD, and Shibboleth/SAML/ADFS. More information on how to get set up here.
Community Training
Training powered by Localist
If you are reading this, then you’ve enlisted the help of Localist to educate both your Admins and Users on your new calendar solution. Our team of experts will be providing tailored training resources to get your community up to speed as fast as possible. These resources include a customized Video Library and/or Calendar Documentation. If you purchased our Community Training package, you will receive both!
Scope of Service
In order for development to commence, the following conditions must be met: 1) Contract signed, 2) Topics submitted and 3) “Implementation complete” status is reached or to the point where screenshots and directions can be provided in the videos. Once the last of these three conditions have been met, completed videos will be returned within 30 days.
(1) Development
Localist will create, and perform, personalized videos based on your selected topics. These videos will reference screenshots of your Localist platform, so it must be as close to “Implementation Complete” as possible for consistency.
- Branding: Light customizations include fonts, colors and your choice of a dark or light variant.
- Topics: You may select your topics from the predetermined list provided by Localist. These cannot be divided or combined in any way.
(2) Publishing
Once your Video Library has been completed, Localist will share the edited mp4 files via Google Drive. Your team will be responsible for hosting and publishing outside of Google Drive.
- Localist can provide a CTA URL and add it to your calendar homepage for easy access.
Take Your Pick!
Dark Variant
Light Variant
Scope of Service
In order for development to commence, the following conditions must be met: 1) Contract signed, 2) Topics submitted and 3) “Implementation complete” status is reached or to the point where screenshots and directions can be provided in the documentation. Once the last of these three conditions have been met, completed documentation will be returned within 30 days.
(1) Development
Localist will develop personalized documentation based on your selected topics. The documentation will reference how your Localist platform is set up, so your platform must be as close to “Implementation Complete” as possible for consistency. Screenshots will not be included as a part of documentation development. All media must be added by the customer after the written documentation as been delivered.
- Topics: You may select your topics from the predetermined list provided by Localist. These cannot be divided or combined in any way.
(2) Publishing
Once your documentation has been completed, Localist will share the files via Google Drive. Your team will be responsible for hosting outside of Google Drive. Once hosted on your end, Localist can add links to your User Help Page theme template, which will be available at yourcustomdomain.com/help/about.
If you would like your Calendar Documentation published elsewhere, you will be responsible for the hosting and creation of that page.
Take Your Pick!
Setup Playbook: Enterprise
Timelines
The following are recommended timelines for implementation. While the exact time dedicated to each task may vary, the order in which you implement the platform must follow the “Order of Events” as outlined below.
| Week 1 | Onboarding + Platform Tour | Onboarding Prep | Onboarding Prep | Onboarding Prep |
| Week 2 |
1. Classification > Events 2. Technical Setup |
Platform Tour | Platform Tour | Platform Tour |
| Week 3 | Final Touches | Classification & Start Technical Setup | Classification & Start Technical Setup | Classification & Start Technical Setup |
| Week 4 | Launch | Complete Classification + Start Adding Events | … | … |
| Week 5 | Complete Event Transition + Technical Setup | Start Adding Events | … | |
| Week 6 | Platform Review Call | … | … | |
| Week 7 | Final Touches | Complete Technical Setup | Start Adding Events | |
| Week 8 | Launch | … | … | |
| Week 9 | … | … | ||
| Week 10 | Final Touches | … | ||
| Week 11 | … | Complete Technical Setup | ||
| Week 12 | Launch | … | ||
| Week 13 | … | |||
| Week 14 | Final Touches | |||
| Week 15 | … | |||
| Week 16 | Launch |
Fast Track
The following is an all inclusive list of features, so depending on your orgs needs and goals, you may or may not use certain features. Consult with your implementation specialist to evaluate how certain features may more directly impact your timeline.
Order of Events
The following takes into account all Localist setup features and outlines the order in which they should be completed. Parts (1), (2) and (3) can be completed in parallel.
Implementation Map: Premium
Timelines
The following are recommended timelines for implementation. While the exact time dedicated to each task may vary, the order in which you implement the platform must follow the “Order of Events” as outlined below.
| Week 1 | Welcome Call + Kickoff Call | Welcome Call | Welcome Call | Welcome Call |
| Week 2 |
1. Classification > Events 2. Technical Setup |
Kickoff Call | Kickoff Call | Kickoff Call |
| Week 3 | Platform Review Call + Final Touches | Classification & Start Technical Setup | Classification & Start Technical Setup | Classification & Start Technical Setup |
| Week 4 | Launch | Complete Classification + Start Adding Events | … | … |
| Week 5 | Complete Event Transition + Technical Setup | Start Adding Events | … | |
| Week 6 | Platform Review Call | … | … | |
| Week 7 | Final Touches | Complete Technical Setup | Start Adding Events | |
| Week 8 | Launch | … | … | |
| Week 9 | Platform Review Call | … | ||
| Week 10 | Final Touches | … | ||
| Week 11 | … | Complete Technical Setup | ||
| Week 12 | Launch | … | ||
| Week 13 | … | |||
| Week 14 | Platform Review Call | |||
| Week 15 | Final Touches | |||
| Week 16 | Launch |
Order of Events
Implementation steps are split into two categories: Content and Technical. Each section has an order of steps, but the sections as a whole can (and should) be worked on in parallel. Features in red are not available with the Premium Plan.
| 1. Classification | 1. Brand Template Development |
| Filters | 2. Theme Editor Updates & Additions |
| Custom Fields | 3. CSS Customizations & Clean up |
| Places + Groups/Departments | |
| Tags & Keywords | Custom Domain + SSL |
| x | |
| 2. Add Events (max = 500/year) | Single-sign On |
| Submission Form | |
| Feeds | Global Options |
| Bulk Add | |
| x | |
| 3. Promotion | |
| Channels | |
| Widgets
– Custom Widget Templates |
|
| Featured & Sponsored |
Scheduled Calls
The following calls are staples in the implementation process and are integral to your organization’s success with Localist.
| Host | Customer Success Manager | Implementation Specialist | Implementation Specialist |
| Who should attend? | Main point of contact (required) + second in command (optional) | Main point of contact (required) + key decision makers (tech/design or lead calendar admins – optional) | Main point of contact (required) + only those who also attended the Kickoff Call |
| What will be covered? | Org/dep insight, past event marketing/calendar experience, Localist goals and implementation resources. | High-level information about the platform in order for you to devise a game plan for launch. | Thorough platform review, suggestions and actionable feedback following best practices, promotion strategies and metrics to track. |
| What should you prepare? | Scope of Services questions & Year #1 goals | Browse your new platform & admin dash | Send support a list of remaining questions & double check your Implementation Tracker. |
Implementation Map: Professional
Timelines
The following are recommended timelines for implementation. While the exact time dedicated to each task may vary, the order in which you implement the platform must follow the “Order of Events” as outlined below.
| Week 1 | Welcome Call + Kickoff Call | Welcome Call | Welcome Call | Welcome Call |
| Week 2 |
1. Classification > Events 2. Technical Setup |
Kickoff Call | Kickoff Call | Kickoff Call |
| Week 3 | Pre-Launch Call + Final Touches | Classification & Start Technical Setup | Classification & Start Technical Setup | Classification & Start Technical Setup |
| Week 4 | Launch | Complete Classification + Start Adding Events | … | … |
| Week 5 | Complete Event Transition + Technical Setup | Start Adding Events | … | |
| Week 6 | Pre-Launch | … | … | |
| Week 7 | Final Touches | Complete Technical Setup | Start Adding Events | |
| Week 8 | Launch | … | … | |
| Week 9 | Pre-Launch Call | … | ||
| Week 10 | Final Touches | … | ||
| Week 11 | … | Complete Technical Setup | ||
| Week 12 | Launch | … | ||
| Week 13 | … | |||
| Week 14 | Pre-Launch Call | |||
| Week 15 | Final Touches | |||
| Week 16 | Launch |
Order of Events
Implementation steps are split into two categories: Content and Technical. Each section has an order of steps, but the sections as a whole can (and should) be worked on in parallel. Features in red are not available with the Professional Plan.
| 1. Classification | 1. Brand Template Development |
| Filters | 2. Theme Editor Updates & Additions |
| Custom Fields | 3. CSS Customizations & Clean up |
| Places + Groups/Departments | |
| Tags & Keywords | Custom Domain + SSL |
| x | |
| 2. Add Events | Single-sign On |
| Submission Form | |
| Feeds | Global Options |
| Bulk Add | |
| x | |
| 3. Promotion | |
| Channels (max = 3) | |
| Widgets
– Custom Widget Templates |
|
| Featured & Sponsored |
Scheduled Calls
The following calls are staples in the implementation process and are integral to your organization’s success with Localist.
| Host | Customer Success Manager | Implementation Specialist | Implementation Specialist |
| Who should attend? | Main point of contact (required) + second in command (optional) | Main point of contact (required) + key decision makers (tech/design or lead calendar admins – optional) | Main point of contact (required) + only those who also attended the Kickoff Call |
| What will be covered? | Org/dep insight, past event marketing/calendar experience, Localist goals and implementation resources. | High-level information about the platform in order for you to devise a game plan for launch. | Thorough platform review, suggestions and actionable feedback following best practices, promotion strategies and metrics to track. |
| What should you prepare? | Scope of Services questions & Year #1 goals | Browse your new platform & admin dash | Send support a list of remaining questions & double check your Implementation Tracker. |
Scope of Services: Brand Template Set-up
If you are reading this you’ve purchased Brand Template set-up from our team of experts to help provide a seamless online experience for your audience. We can’t wait to see what magic we’re able to create together! If you just purchased your Wrapper Setup, please complete the form below once you have read through this guide. By completing the form, you are certifying that you have read this guide in its entirety and that you are ready to complete the branding survey.
The Branding Process
-
Branding Survey
Branding development will not commence until Localist receives a completed survey.
- Localist can only guarantee a 30 business day turnaround for a complete branded platform starting from the day the survey is submitted.
- All styles must be clearly defined in the survey or available in the Brand Template or web page URL. Branding cannot be based off of customer created mock ups.
-
Brand Template
Localist builds the customer’s Brand Template. This tools is what applies your website’s header and footer around your Localist content.
- The header and footer to be used in the Brand Template must already be fully built, styled and available together in the same template or web page URL. Localist will not build, customize or piece together header and footers from different pages.
- All assets provided in the wrapper source (CSS, images, etc.) must be served over secure (https) links if SSL is to be implemented on your Localist platform.
- If requested, Localist will add a customer provided hero image to the wrapper if the template does not include one.
- JavaScript development and/or modifications of any kind are not included. These include, but are not limited to, drop-downs, pop-ups or expands.
-
Styles
Localist will remedy any CSS conflicts and apply the following CSS customizations where applicable to the customer’s brand:
- Font families and sizes
- Colors and background colors
- Borders
- Shading
Responsive Design
Localist will maintain the responsiveness of the Brand Template and Localist platform only if the SILK template is responsive. If the template or web page is not responsive, corrective CSS will not be implemented.Theme Editor
In addition to the above CSS customizations, Localist may also complete the following HTML Theme Editor customizations per the customer’s request.- Change photo sizes for listings and landing pages.
-
First Draft
Once the Brand Template and style clean up has been completed by Localist, the customer will receive a completed draft. At this time the customer may request changes to only the above mentioned CSS and Theme Editor customizations. The customer has 10 business days to review the draft and request any tweaks or changes. All changes must be requested at one time.
- HEADS UP: All requested changes require a 2 business day minimum turn-around.
-
Final Approval
After the requested changes have been implemented according to the customer request, the creation step of the Wrapper Setup will be Complete.
- HEADS UP: If the customer does not reply or request changes within 10 business days, the Wrapper will be considered Complete.
-
Grace Period
After the Wrapper is considered Complete, the customer has 20 business days to request additional tweaks. We understand it can be hard to catch everything the first time, or once it’s ‘in the wild’ things come up, which is why we provide the Grace Period.
Brand Template Set-up Timeline
The following timeline reflects the maximum amount of time (business days) between each step.
Brand Survey
Localist can only guarantee a 30 business day turn around from the day the Refresh Bold Branding Survey is SUBMITTED to us. If your header/footer changes, then the 30 business day timeline starts over. Contact support@localist.com if you have any questions.
Bookmarks
Click an image to view the full size!
Listing Customizations
Sponsored Events
Featured Events
Landing Page Customizations
Login Lightbox
Submission Guidelines
User Help
Homepage Widgets
Other Widgets
Channels
Light Branding
Hero & Background Images
Platform Nav
WCAG 2.1 Compliance
L1
| Compliant | WCAG Level | WCAG Criteria | WCAG Recommendation |
|---|---|---|---|
| Yes | A | 1.1.1 Non-text Content | All img tags must have alt attributes. |
| Yes | A | 1.1.1 Non-text Content | If short alt text is sufficient to describe an image, provide the short text via the image’s alt attribute. |
| Yes | A | 1.1.1 Non-text Content | If a short text alternative is not sufficient to describe an image (such as in a chart, graph, or diagram), provide short text via the image’s alt attribute, and include a long description in nearby text. |
| Yes | A | 1.1.1 Non-text Content | If an image or icon is used as a button or link, the image has a text alternative sufficient to describe the purpose of the button or link. |
| Yes | A | 1.1.1 Non-text Content | Images that are decorative, used for formatting, or contain content already conveyed in text have a null alt attribute or are implemented as CSS background images. |
| Yes | A | 1.1.1 Non-text Content | Frames and iFrames have descriptive titles. |
| Yes | A | 1.1.1 Non-text Content | Minimize the number of adjacent links to the same destination by combining adjacent images and text into a single link, rather than creating a separate link for each element. |
| Yes | A | 1.2.1 Audio-only and Video-only (Prerecorded) | For pre-recorded audio (without video), provide a descriptive transcript that includes dialogue and all other meaningful sound. |
| Yes | A | 1.2.1 Audio-only and Video-only (Prerecorded) | For pre-recorded video (without audio), provided a text alternative or audio descriptions that provide the same information presented |
| Yes | A | 1.2.2 Captions (Prerecorded) | Provide captions for prerecorded audio content in non-live synchronized media. |
| Yes | A | 1.2.3 Audio Description or Media Alternative (Prerecorded) | For non-live video, provide a descriptive transcript or an audio description. |
| Yes | A | 1.3.1 Info and Relationships | Use semantic markup to designate headings, lists, figures, emphasized text, etc. |
| Yes | A | 1.3.1 Info and Relationships | Organize pages using properly nested HTML headings. |
| Yes | A | 1.3.1 Info and Relationships | Use ARIA landmarks and labels to identify regions of a page. |
| Yes | A | 1.3.1 Info and Relationships | Reserve tables for tabular data, use table headers appropriately, and use table captions. |
| Yes | A | 1.3.1 Info and Relationships | When the appearance of text conveys meaning, also use appropriate semantic markup. |
| Yes | A | 1.3.1 Info and Relationships | Avoid emulating links and buttons. Use the a and button tags appropriately. Avoid using a tags for buttons. Avoid using div, span, etc. tags for links or buttons. |
| Yes | A | 1.3.1 Info and Relationships | Avoid using whitespace characters for layout purposes. |
| Yes | A | 1.3.2 Meaningful Sequence | Ensure that the source order presents content meaningfully. When the page is viewed without styles, all content on the page should still appear in a meaningful and logical order. |
| Yes | A | 1.3.3 Sensory Characteristics | Do not identify content based on its color, size, shape, position, sound, or other sensory characteristics. |
| Yes | A | 1.3.3 Sensory Characteristics | Do not convey information solely through icons or symbols. |
| Yes | A | 1.4.1 Use of Color | Links should always be easily identifiable through non-color means, including both default and hover states. The easiest and most conventional way to signify links is underlining. |
| Yes | A | 1.4.1 Use of Color | Required fields and fields with errors must include some non-color way to identify them. |
| Yes | A | 1.4.1 Use of Color | When the color of words, backgrounds, or other content is used to convey information, also include the information in text. |
| N/A | A | 1.4.2 Audio Control | Do not have audio that plays automatically on the page. When providing audio, also provide an easy way to disable the audio and adjust the volume. |
| Yes | A | 2.1.1 Keyboard | Avoid implementing access keys. When access keys and other keyboard shortcuts are implemented, they must not interfere with existing browser and screen reader provided shortcuts. |
| Yes | A | 2.1.1 Keyboard | All functionality should be available to a keyboard without requiring specific timing of keystrokes, unless the functionality cannot be provided by a keyboard alone. |
| Yes | A | 2.1.1 Keyboard | Avoid relying exclusively on pointer-driven events, such as onmouseover, to provide functionality when scripting. Generally, such functionality will also require scripting for keyboard operability. |
| Yes | A | 2.1.1 Keyboard | In general, avoid using scripts to remove focus from an element until the user moves focus manually. |
| Yes | A | 2.1.2 No Keyboard Trap | Ensure keyboard focus is never trapped on an element without an obvious way to move focus out of the element. Make sure the user can move focus to and from all focusable elements using a keyboard only. |
| N/A | A | 2.1.4 Character Key Shortcuts | If a keyboard shortcut uses only letter (including upper- and lower-case letters), punctuation, number, or symbol characters, then the user must be able to disable the shortcut, remap the shortcut, or limit the shortcut to only when a particular interactive element has focus. |
| Yes | A | 2.2.1 Timing Adjustable | Do not require time limits to complete tasks unless absolutely necessary. If a time limit is necessary, the time limit should be at least 20 hours, or it can be extended, adjusted, or disabled. |
| Yes | A | 2.2.2 Pause, Stop, Hide | Items on the page should not automatically move, blink, scroll, or update, including carousels. If content does automatically move, blink, scroll, or update, provide a way to pause, stop, or hide the moving, blinking, scrolling, or updating. |
| Yes | A | 2.3.1 Three Flashes or Below Threshold | Do not provide any content that flashes more than three times in any 1-second period. |
| Yes | A | 2.4.2 Page Titled | Make sure each web page has a title tag that is descriptive, informative, and unique. |
| Yes | A | 2.4.3 Focus Order | Create a logical tab order through links, form controls, and interactive objects. |
| Yes | A | 2.4.3 Focus Order | When inserting content into the DOM, insert the content immediately after the triggering element, or use scripting to manage focus in an intuitive way. When triggering dialogs and menus, make sure those elements follow their trigger in the focus order in an intuitive way. When content is dismissed or removed, place focus back on the trigger. |
| Yes | A | 2.4.3 Focus Order | Avoid using tab index values greater than 0. |
| Yes | A | 2.4.4 Link Purpose (In Context) | The purpose of each link can be determined from the link text alone, or from the link text and the containing paragraph, list item, or table cell, or the link text and the title attribute. |
| Yes | A | 2.4.4 Link Purpose (In Context) | If the visible text alone is not sufficient to convey meaning, use advanced techniques to provide additional meaning, such as ARIA attributes, screen reader only text, or the title attribute. |
| Yes | A | 2.5.1 Pointer Gestures | Do not require multipoint or path-based gestures (e.g. pinching, swiping, dragging) for functionality unless the gesture is essential to the functionality. |
| Yes | A | 2.5.2 Pointer Cancellation | Avoid triggering functionality on down-events, such as onmousedown. Use events such as onclick instead. |
| Yes | A | 2.5.2 Pointer Cancellation | If a function is triggered on an up-event (e.g. onmouseup), provide a way to abort or undo the function. |
| Yes | A | 2.5.3 Label in Name | The accessible name for a UI element must contain any visual label for the element. Accessible names for UI elements should match visual labels as closely as possible. |
| Yes | A | 2.5.4 Motion Actuation | Avoid activating functionality through motion (e.g. shaking a phone). If motion triggers functionality, provide a way to disable the motion trigger, and provide an alternative way to activate the functionality. |
| Yes | A | 3.1.1 Language of Page | Provide a lang attribute on the page’s html element. |
| Yes | A | 3.1.1 Language of Page | When a visual label is present for an interactive element (e.g. link or form control), the accessible name of the element should contain the visual label. |
| Yes | A | 3.2.1 On Focus | When the focus change, the page should not cause a change in page content, spawn a new browser window, submit a form, case further change in focus, or cause any other change that disorients the user. |
| Yes | A | 3.2.2 On Input | When a user inputs information or interacts with a control, the page should not cause a change in page content, spawn a new browser window, submit a form, case further change in focus, or cause any other change that disorients the user. If an input causes such a change, the user must be informed ahead of time. |
| Yes | A | 3.3.1 Error Identification | Programmatically indicate required fields using the required or aria-required attributes. Also, visually indicate required fields in the form’s instructions or form labels. Do not indicate required fields for CSS alone. |
| Yes | A | 3.3.1 Error Identification | Make errors easy to discover, identify, and correct. |
| Yes | A | 3.3.1 Error Identification | Identify errors using aria-invalid. |
| Yes | A | 3.3.2 Labels or Instructions | Use semantic, descriptive labels for inputs. Visually position labels in a consistent way that makes associating labels with form controls easy. Do not rely on placeholder text in lieu of an HTML label. |
| Yes | A | 3.3.2 Labels or Instructions | Provide text instructions at the beginning of a form or set of fields that describes the necessary input. |
| Yes | A | 3.3.2 Labels or Instructions | When providing inline help text, use aria-describedby to associate the help text with the input. |
| Yes | A | 4.1.1 Parsing | Validate all page HTML, and avoid significant validation / parsing errors. |
| Yes | A | 4.1.2 Name, Role, Value | Avoid creating custom widgets when HTML elements already exist. For example, use a and button tags appropriately. |
| Yes | A | 4.1.2 Name, Role, Value | When creating a custom interactive widget, consult the ARIA Authoring Practices Document. Use ARIA labels, descriptions, roles, states, and properties to expose information about the component. |
| Yes | A | 4.1.2 Name, Role, Value | Use ARIA to enhance accessibility only when HTML is not sufficient. Use caution when providing ARIA roles, states, and properties. |
L2
| Compliant | WCAG Level | WCAG Criteria | WCAG Recommendation |
|---|---|---|---|
| N/A | AA | 1.2.4 Captions (Live) | Provide captions for live audio and video. |
| N/A | AA | 1.2.5 Audio Description (Prerecorded) | Videos should include “radio style” narration so that content makes sense if someone is consuming just the audio track. Include any text elements in the narration. |
| Yes | AA | 1.3.4 Orientation | All content and functionality should be available regardless of whether a mobile device is oriented vertically or horizontally, unless the orientation of the device is absolutely essential. |
| Yes | AA | 1.3.5 Identify Input Purpose | If a form field asks for information about the user and if there is an appropriate HTML autocomplete attribute, include that autocomplete attribute. |
| Yes | AA | 1.4.3 Contrast (Minimum) | Text (including images of text) have a contrast ratio of at least 4.5:1. For text and images of that is at least 24px and normal weight or 19px and bold, use a contrast ratio that is at least 3:1. |
| Yes | AA | 1.4.4 Resize text | Ensure that there is no loss of content or functionality when text resizes. |
| Yes | AA | 1.4.4 Resize text | Define texts and text containers in relative units (percents, ems, rems) rather than in pixels. |
| Yes | AA | 1.4.5 Images of Text | Avoid images of text, except in cases such as logos. |
| Yes | AA | 1.4.10 Reflow | Provide responsive stylesheets such that content can be displayed at 320px wide without horizontal scrolling. (Content which must be displayed in two dimensions, such as maps and data tables, may have horizontal scrolling.) |
| Yes | AA | 1.4.11 Non-text Contrast | Color contrast for graphics and interactive UI components must be at least 3:1 so that different parts can be distinguished. |
| Yes | AA | 1.4.11 Non-text Contrast | When providing custom states for elements (e.g. hover, active, focus), color contrast for those states should be at least 3:1. |
| Yes | AA | 1.4.12 Text Spacing | Avoid using pixels for defining the height and spacing (e.g. height, line height, etc) of text boxes. |
| Yes | AA | 1.4.13 Content on Hover or Focus | For tooltips, follow corresponding ARIA authoring practice. |
| Yes | AA | 1.4.13 Content on Hover or Focus | For content that appears on hover and focus: the content should be dismissible with the escape key; the content itself can be hovered over; and the content remains available unless it is dismissed, it is no longer relevant, or the user removes hover and focus. |
| Yes | AA | 1.4.13 Content on Hover or Focus | To the extent possible, content that appears on hover or focus should not obscure other content, unless it presents a form input error. or can be dismissed with the escape key. |
| Yes | AA | 2.4.5 Multiple Ways | Each website should include at least two of the following: a list of related pages; table of contents; site map; search; or list of all pages. |
| Yes | AA | 2.4.6 Headings and Labels | Ensure that on each page, headings, landmark labels, and form labels are unique unless the structure provides adequate differentiation between them. |
| Yes | AA | 2.4.7 Focus Visible | Provide keyboard focus styles that are highly visible, and make sure that a visible element has focus at all times when using a keyboard. Do not rely on browser default focus styles. |
| Yes | AA | 3.1.2 Language of Parts | If a portion of the page is in a different language, use the lang attribute on that part. |
| Yes | AA | 3.2.3 Consistent Navigation | When components are repeated across web page, they should appear in the same relative order with regard to other repeated components on each web page where they appear. |
| Yes | AA | 3.2.3 Consistent Navigation | When a navigation menu is presented on multiple pages, the links should appear in the same order on each page. |
| Yes | AA | 3.2.4 Consistent Identification | When components have the same functionality across several web pages, the components are labeled consistently on each page. |
| Yes | AA | 3.3.3 Error Suggestion | If an input error is detected and if suggestions for correction are known, provide suggestions for fixing the submission. |
| Yes | AA | 3.3.4 Error Prevention (Legal, Financial, Data) | Provide easy ways to confirm, correct, or reverse a user action where a mistake would cause a serious real-world consequence (e.g. submitting financial data, entering into a legal agreement, submitting test data, or making a transaction). |
| Yes | AA | 4.1.3 Status Messages | When conveying a status message, use ARIA live regions or ARIA alerts to announce the message to screen reader users. |
L3
| Compliant | WCAG Level | WCAG Criteria | WCAG Recommendation |
|---|---|---|---|
| Yes | AAA | 1.2.6 Sign Language (Prerecorded) | Sign language interpretation is provided for all prerecorded audio content in synchronized media. |
| Yes | AAA | 1.2.7 Extended Audio Description (Prerecorded) | Where pauses in foreground audio are insufficient to allow audio descriptions to convey the sense of the video, extended audio description is provided for all prerecorded video content in synchronized media. |
| N/A | AAA | 1.2.8 Media Alternative (Prerecorded) | An alternative for time-based media is provided for all prerecorded synchronized media and for all prerecorded video-only media. |
| N/A | AAA | 1.2.9 Audio-only (Live) | An alternative for time-based media that presents equivalent information for live audio-only content is provided. |
| Yes | AAA | 1.3.6 Identify Purpose | In content implemented using markup languages, the purpose of User Interface Components, icons, and regions can be programmatically determined. |
| Yes | AAA | 1.4.6 Contrast (Enhanced) | The visual presentation of text and images of text has a contrast ratio of at least 7:1. |
| N/A | AAA | 1.4.7 Low or No Background Audio | For prerecorded audio-only content that (1) contains primarily speech in the foreground, (2) is not an audio CAPTCHA or audio logo, and (3) is not vocalization intended to be primarily musical expression such as singing or rapping, at least one of the following is true: |
| Yes | AAA | 1.4.8 Visual Presentation | For the visual presentation of blocks of text, a mechanism is available to achieve the following: |
| Yes | AAA | 1.4.9 Images of Text (No Exception) | Images of text are only used for pure decoration or where a particular presentation of text is essential to the information being conveyed. |
| Yes | AAA | 2.1.3 Keyboard (No Exception) | All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes. |
| Yes | AAA | 2.2.3 No Timing | Timing is not an essential part of the event or activity presented by the content, except for non-interactive synchronized media and real-time events. |
| Yes | AAA | 2.2.4 Interruptions | Interruptions can be postponed or suppressed by the user, except interruptions involving an emergency. |
| Yes | AAA | 2.2.5 Re-authenticating | When an authenticated session expires, the user can continue the activity without loss of data after re-authenticating. |
| N/A | AAA | 2.2.6 Timeouts | Users are warned of the duration of any user inactivity that could cause data loss, unless the data is preserved for more than 20 hours when the user does not take any actions. |
| Yes | AAA | 2.3.2 Three Flashes | Web pages do not contain anything that flashes more than three times in any one second period. |
| Does not support | AAA | 2.3.3 Animation from Interactions | Motion animation triggered by interaction can be disabled, unless the animation is essential to the functionality or the information being conveyed. |
| Yes | AAA | 2.4.8 Location | Information about the user’s location within a set of Web pages is available. |
| Yes | AAA | 2.4.9 Link Purpose (Link Only) | A mechanism is available to allow the purpose of each link to be identified from link text alone, except where the purpose of the link would be ambiguous to users in general. |
| Supports with exceptions | AAA | 2.4.10 Section Headings | Section headings are used to organize the content. |
| Yes | AAA | 2.5.5 Target Size | The size of the target for pointer inputs is at least 44 by 44 CSS pixels except when: |
| Yes | AAA | 2.5.6 Concurrent Input Mechanisms | Web content does not restrict use of input modalities available on a platform except where the restriction is essential, required to ensure the security of the content, or required to respect user settings. |
| Yes | AAA | 3.1.3 Unusual Words | A mechanism is available for identifying specific definitions of words or phrases used in an unusual or restricted way, including idioms and jargon. |
| Yes | AAA | 3.1.4 Abbreviations | A mechanism for identifying the expanded form or meaning of abbreviations is available. |
| Yes | AAA | 3.1.5 Reading Level | When text requires reading ability more advanced than the lower secondary education level after removal of proper names and titles, supplemental content, or a version that does not require reading ability more advanced than the lower secondary education level, is available. |
| Yes | AAA | 3.1.6 Pronunciation | A mechanism is available for identifying specific pronunciation of words where meaning of the words, in context, is ambiguous without knowing the pronunciation. |
| Yes | AAA | 3.2.5 Change on Request | Changes of context are initiated only by user request or a mechanism is available to turn off such changes. |
| Yes | AAA | 3.3.5 Help | Context-sensitive help is available. |
| Yes | AAA | 3.3.6 Error Prevention (All) | For Web pages that require the user to submit information, at least one of the following is true: |
Resource Links
Technical
- VPAT: https://support.localist.com/vpat/
- 508 Compliance: https://support.localist.com/508-compliance/
- WCAG 2.0 (Accessibility): https://support.localist.com/wcag-2/
Customer Operations
Implementation Maps
- Enterprise: https://support.localist.com/enterprise/
- Professional: https://support.localist.com/professional/
- Premium: https://support.localist.com/premium/
Scopes of Service
- Scope of Services: https://support.localist.com/services/
- Support Bold: https://support.localist.com/bold/
- Refresh Bold: https://support.localist.com/refresh-bold/
- Wrapper Setup: https://support.localist.com/wrapper-setup/
- Community Training: https://support.localist.com/training/
Other
- Bookmarks: https://support.localist.com/bookmarks/
Voluntary Product Accessibility Template®
Version 1.6
The purpose of the Voluntary Product Accessibility Template, or VPAT™, is to assist Federal contracting officials and other buyers in making preliminary assessments regarding the availability of commercial “Electronic and Information Technology” products and services with features that support accessibility. It is assumed and recommended that offerers will provide additional contact information to facilitate more detailed inquiries.
The first table of the Template provides a summary view of the Section 508 Standards. The subsequent tables provide more detailed views of each subsection. There are three columns in each table. Column one of the Summary Table describes the subsections of subparts B and C of the Standards. The second column describes the supporting features of the product or refers you to the corresponding detailed table, e.g., “equivalent facilitation.” The third column contains any additional remarks and explanations regarding the product. In the subsequent tables, the first column contains the lettered paragraphs of the subsections. The second column describes the supporting features of the product with regard to that paragraph. The third column contains any additional remarks and explanations regarding the product.
Date: 02/20/2018
Name of Product: Localist Calendar
Contact for more Information (name/phone/email): Mykel Nahorniak, 703-626-1528, myke@localist.com
Summary Table
VPAT™
Voluntary Product Accessibility Template®
| Criteria | Supporting Features | Remarks and explanations |
|---|---|---|
| Section 1194.21 Software Applications and Operating Systems | N/A | |
| Section 1194.22 Web-based Internet Information and Applications | Supported | |
| Section 1194.23 Telecommunications Products | N/A | |
| Section 1194.24 Video and Multi-media Products | N/A | |
| Section 1194.25 Self-Contained, Closed Products | N/A | |
| Section 1194.26 Desktop and Portable Computers | N/A | |
| Section 1194.31 Functional Performance Criteria | Supported | |
| Section 1194.41 Information, Documentation and Support | Supported |
Section 1194.22 Web-based intranet and Internet information and applications- Detail™
Voluntary Product Accessibility Template®
| Criteria | Supporting Features | Remarks and explanations |
|---|---|---|
| (a) A text equivalent for every non-text element shall be provided (e.g., via “alt”, “longdesc”, or in element content). | All | |
| (b) Equivalent alternatives for any multimedia presentation shall be synchronized with the presentation. | N/A | |
| (c) Web pages shall be designed so that all information conveyed with color is also available without color, for example from context or markup. | All | |
| (d) Documents shall be organized so they are readable without requiring an associated style sheet. | All | |
| (e) Redundant text links shall be provided for each active region of a server-side image map. | N/A | |
| (f) Client-side image maps shall be provided instead of server-side image maps except where the regions cannot be defined with an available geometric shape. | N/A | |
| (g) Row and column headers shall be identified for data tables. | All | |
| (h) Markup shall be used to associate data cells and header cells for data tables that have two or more logical levels of row or column headers. | All | |
| (i) Frames shall be titled with text that facilitates frame identification and navigation | All | |
| (j) Pages shall be designed to avoid causing the screen to flicker with a frequency greater than 2 Hz and lower than 55 Hz. | All | |
| (k) A text-only page, with equivalent information or functionality, shall be provided to make a web site comply with the provisions of this part, when compliance cannot be accomplished in any other way. The content of the text- only page shall be updated whenever the primary page changes. | N/A | |
| (l) When pages utilize scripting languages to display content, or to create interface elements, the information provided by the script shall be identified with functional text that can be read by Assistive Technology. | All | |
| (m) When a web page requires that an applet, plug-in or other application be present on the client system to interpret page content, the page must provide a link to a plug-in or applet that complies with 1194.21(a) through (l). | N/A | |
| (n) When electronic forms are designed to be completed on-line, the form shall allow people using Assistive Technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues. | All | |
| (o) A method shall be provided that permits users to skip repetitive navigation links. | All | |
| (p) When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required. | All |
Section 1194.31 Functional Performance Criteria – Detail™
VPAT™
Voluntary Product Accessibility Template®
| Criteria | Supporting Features | Remarks and explanations |
|---|---|---|
| (a) At least one mode of operation and information retrieval that does not require user vision shall be provided, or support for Assistive Technology used by people who are blind or visually impaired shall be provided. | All | |
| (b) At least one mode of operation and information retrieval that does not require visual acuity greater than 20/70 shall be provided in audio and enlarged print output working together or independently, or support for Assistive Technology used by people who are visually impaired shall be provided. | All | |
| (c) At least one mode of operation and information retrieval that does not require user hearing shall be provided, or support for Assistive Technology used by people who are deaf or hard of hearing shall be provided | All | |
| (d) Where audio information is important for the use of a product, at least one mode of operation and information retrieval shall be provided in an enhanced auditory fashion, or support for assistive hearing devices shall be provided. | N/A | Audio information is not important for the use of Localist. |
| (e) At least one mode of operation and information retrieval that does not require user speech shall be provided, or support for Assistive Technology used by people with disabilities shall be provided. | All | |
| (f) At least one mode of operation and information retrieval that does not require fine motor control or simultaneous actions and that is operable with limited reach and strength shall be provided. | All |
Section 1194.41 Information, Documentation and Support – Detail
VPAT™
Voluntary Product Accessibility Template®
| Criteria | Supporting Features | Remarks and explanations |
|---|---|---|
| (a) Product support documentation provided to end-users shall be made available in alternate formats upon request, at no additional charge | Yes | Formats not included in “no additional charge:” video. |
| (b) End-users shall have access to a description of the accessibility and compatibility features of products in alternate formats or alternate methods upon request, at no additional charge. | All | |
| (c) Support services for products shall accommodate the communication needs of end-users with disabilities. | All |