Design Style Guide for Organizations (with Accessibility Focus) 

[Name of Organization]  

Date of Last Update: [date] 

1. Introduction 

This design style guide provides a framework for creating consistent, professional, and accessible communications and digital experiences for [Name of Organization]. Adherence to these guidelines ensures that our brand is presented cohesively and that our content is usable by the widest possible audience, including individuals with disabilities. 

Accessibility is not just a compliance requirement; it is a commitment to inclusivity and equity, reflecting our institution’s values. This guide incorporates principles from the Web Content Accessibility Guidelines (WCAG) 2.1 AA as a minimum standard. 

2. Our Brand Identity (Brief Overview) 

  [Link to full brand guidelines if applicable] 

  • Mission & Values: Briefly state the institution’s mission and how accessibility aligns with it. 
  • Logo Usage: [Covered in detail in main brand guidelines] Ensure sufficient contrast when placing logos on different backgrounds. Provide alternative text for logos used as images. 
  • Tone of Voice: [Covered in detail in main brand guidelines] Strive for clear, concise, and easy-to-understand language. 

3. Color Palette 

Our color palette is designed to be vibrant, reflect our institution’s identity, and meet accessibility standards for contrast. 

  • Primary Colors:  
  • [Primary Color 1 Name & Hex Code] (e.g., University Blue #0033A0)  
  • Usage: Primary calls to action, headers, large blocks of color. 
  • Accessibility: Ensure text placed on this color has a contrast ratio of at least 4.5:1 (AA) for normal text and 3:1 for large text (18pt or 14pt bold). 
  • [Primary Color 2 Name & Hex Code] (e.g., Spirit Gold #F2A900)  
  • Usage: Accent color, secondary calls to action. 
  • Accessibility: Verify contrast against background and foreground elements. Particularly important for text. 
  • Secondary Colors:  
  • [Secondary Color 1 Name & Hex Code] 
  • [Secondary Color 2 Name & Hex Code] 
  • [Secondary Color 3 Name & Hex Code]  
  • Usage: Supporting elements, illustrations, charts, and graphs. 
  • Accessibility: All secondary colors used with text or as meaningful visual cues must meet contrast requirements. 
  • Neutral Colors:  
  • [Dark Gray/Black Name & Hex Code] (e.g., Charcoal #333333) – For body text. 
  • [Medium Gray Name & Hex Code] (e.g., Stone Gray #757575) – For secondary text, borders. 
  • [Light Gray Name & Hex Code] (e.g., Pale Gray #F1F1F1) – For backgrounds. 
  • White #FFFFFF  
  • Accessibility: Pure black text on a pure white background offers high contrast. Grays must be used carefully to ensure sufficient contrast. 
  • Accessibility & Color Contrast:  
  • Normal Text: 4.5:1 against its background. 
  • Large Text (18pt or 14pt bold): 3:1 against its background. 
  • Graphics & UI Components: 3:1 against adjacent colors (e.g., borders of input fields, parts of a chart). 
  • Tools for Checking Contrast:  
  • Color Alone: Do not use color as the sole means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. Use supporting text, icons, patterns, or other visual cues.  
  • Example: Instead of “Click the green button,” use “Click the ‘Submit’ button (green).” 
  • Example: Use patterns in charts and graphs in addition to color to differentiate data series. 

4. Typography 

Clear and legible typography is crucial for accessibility. 

  • Primary Typeface (Headings):  
  • [Font Family Name] (e.g., Open Sans, Lato, Montserrat, Tahoma) 
  • Weights: Bold, Semi-Bold 
  • Usage: Used for H1-H6 headings to establish a clear visual hierarchy. 
  • Secondary Typeface (Body Text):  
  • [Font Family Name] (e.g., Open Sans, Lato, Source Sans Pro, Tahoma) 
  • Weights: Regular, Italic, Bold (use bold sparingly for emphasis within body text). 
  • Usage: Paragraphs, lists, captions, and other long form reading content. 
  • Font Sizing:  
  • Base Body Text Size: Minimum 16px (or 1em/1rem equivalent) for web content. Print materials may vary but should prioritize readability. 
  • Line Height (Leading): At least 1.5 times the font size for body text to improve readability. 
  • Letter Spacing (Tracking) and Word Spacing: Ensure adequate spacing; avoid overly condensed or expanded text. 
  • Readability Considerations:  
  • Choose sans-serif fonts for body text on digital platforms as they are often considered more readable on screens. 
  • Avoid overly decorative or script fonts for essential information. 
  • Ensure sufficient spacing between paragraphs (at least 1.5 times the line height). 
  • Left-align text for most content. Avoid justified text, as it can create uneven spacing (“rivers of white”) that makes reading difficult for some users. 
  • Limit the use of all caps, as it can be harder to read. 

5. Heading Structure (Semantic HTML) 

Proper heading structure is essential for screen reader users to navigate content and for search engine optimization (SEO). 

  • H1 (Heading 1):  
  • Usage: There should be only one H1 per page, representing the main title or subject of that specific page. 
  • Example: <H1>Admissions Requirements</H1> 
  • H2 (Heading 2):  
  • Usage: Major sections within the page. 
  • Example: <H2>Undergraduate Programs</H2>, <H2>Application Deadlines</H2> 
  • H3 (Heading 3):  
  • Usage: Sub-sections within an H2. 
  • Example: Under <H2>Undergraduate Programs</H2>, you might have <H3>Bachelor of Arts</H3> and <H3>Bachelor of Science</H3>. 
  • H4, H5, H6 (Headings 4-6):  
  • Usage: Further sub-sections used as needed to create a logical outline. 
  • Key Principles:  
  • Do Not Skip Levels: Headings must be used in logical order (e.g., H1 → H2 → H3). Do not jump from an H2 to an H4. 
  • Use for Structure, Not Just Style: Do not select a heading level based on its appearance. Use headings to convey the actual structure and hierarchy of the content. Use CSS to style headings according to the visual design. 
  • Conciseness: Keep the heading text clear and concise. 

6. Imagery and Alternative Text 

Images can enhance content but must be accessible. 

  • Alternative Text (Alt Text):  
  • Purpose: Provides a textual description of an image for screen reader users or when an image fails to load. 
  • Requirement: All informative images must have descriptive alt text. 
  • How to Write Good Alt Text:  
  • Be accurate and concise. 
  • Describe the content and function of the image. 
  • If the image contains text, include that text in the alt attribute (unless the text is also present nearby as actual text). 
  • Avoid “image of…” or “picture of…” unless it’s crucial to understanding (e.g., “screenshot of…”). 
  • Decorative Images: Images that are purely decorative and provide no informational value should have an empty alt attribute (alt=””) and role=“presentation” or be implemented as CSS background images. This tells screen readers to ignore them. 
  • Complex Images (Charts, Graphs, Maps):  
  • Provide a detailed text description either in the alt text (if brief enough) or in the surrounding text or via a linked long description. 
  • Ensure data is available in an accessible format (e.g., a table). 
  • Image Licensing and Attribution: Follow institutional policies for image use. 

7. Links and Navigation 

Links should be clear, descriptive, and easy to use. 

  • Link Text:  
  • Descriptive: Link text should make sense out of context. Avoid vague phrases like “Click Here,” “Learn More,” or “Read More” unless accompanied by surrounding text that provides context (e.g., using aria-describedby). 
  • Example (Good): “Read the full <a href=”…”>Academic Calendar</a>.” 
  • Example (Avoid): “For the Academic Calendar, <a href=”…”>click here</a>.” 
  • Visual Cues:  
  • Links should be visually distinct from surrounding text, typically using both color and underlining. 
  • Ensure sufficient contrast for link text against the background. 
  • Keyboard Navigation:  
  • All interactive elements, including links and navigation menus, must be operable using only a keyboard. 
  • A visible focus indicator (e.g., a border or outline) must be present when an element receives keyboard focus. Do not remove or suppress browser default focus indicators unless you replace them with a more obvious custom one. 
  • Navigation order should be logical and intuitive. 

8. Forms 

Forms must be accessible for users to input information effectively. 

  • Labels: All form fields (text inputs, checkboxes, radio buttons, dropdowns) must have clearly associated labels using the <label for=”id”> element. Clicking the label should set focus to the input. 
  • Required Fields: Clearly indicate required fields using text (e.g., “(required)”) and/or an asterisk with an explanation. Use aria-required=”true” on the input. 
  • Error Messages:  
  • Provide clear, specific error messages when input is invalid. 
  • Identify the field(s) in error. 
  • Suggest how to fix the error. 
  • Associate errors programmatically with the respective fields (e.g., using aria-describedby or aria-errormessage). 
  • Keyboard Accessibility: All form controls must be keyboard operable. 
  • Grouping Related Fields: Use <fieldset> and <legend> to group related form controls (e.g., a set of radio buttons for a single question). 

9. Tables 

Data tables should be structured correctly for screen readers. 

  • Use Tables for Tabular Data Only: Do not use tables for layout. 
  • Table Headers: Use <thead> and <th> elements to define row and/or column headers. Use the scope attribute (scope=”col” or scope=”row”) to associate headers with data cells. 
  • Captions: Provide a <caption> element to describe the table’s content. 
  • Simplicity: Keep tables as simple as possible. Avoid complex nested tables if an alternative presentation is feasible. 

10. Multimedia (Audio & Video) 

Multimedia content must be accessible. 

  • Audio Content:  
  • Transcripts: Provide a synchronized transcript for all pre-recorded audio content. 
  • Video Content:  
  • Captions: Provide accurate, synchronized captions for all pre-recorded video content with audio. 
  • Audio Descriptions: Provide audio descriptions for pre-recorded video content to convey important visual information for people who are blind or have low vision. 
  • Transcripts: Provide a transcript for video content as well. 
  • Media Player Controls:  
  • Ensure media players are keyboard accessible and provide controls for play/pause, volume, and toggling captions/audio descriptions. 
  • Avoid auto-playing audio or video or provide a mechanism to stop it. 

11. Document Accessibility (PDFs, Word, PowerPoint) 

Documents created for download or distribution should also be accessible. 

  • Use Templates: Start with accessible templates when available. 
  • Structure: Use built-in heading styles, lists, and table tools. 
  • Alt Text: Add alt text to images. 
  • Meaningful File Names: Use descriptive file names. 
  • PDFs:  
  • Ensure PDFs are “tagged” for accessibility. This usually involves exporting from a source document (like Word or InDesign) with accessibility features enabled. 
  • When converting from Word to PDF ensure the Word document is fully accessible using rich semantics like styles for headings, images have alt text descriptions and when exporting ensure you check the option of “Accessible PDF, or PDF/UA Compliant” 
  • Check reading order. 
  • Specify document language. 
  • Training: Provide training on creating accessible documents using common software. 

12. Web Content (General) 

  • Content Structure: Use semantic HTML5 elements like <main>, <nav>, <aside>, <article>, <section>, <footer> to define page regions. 
  • ARIA (Accessible Rich Internet Applications): Use ARIA roles and attributes judiciously to enhance the accessibility of custom widgets or dynamic content where native HTML semantics are insufficient. Incorrect ARIA usage can create more barriers. 
  • Flashing Content: Avoid content that flashes or blinks more than three times per second, as this can trigger seizures. 
  • Clear Language: Write in plain language. Avoid jargon or provide explanations. 
  • Consistent Navigation: Maintain consistent navigation across the website. 

13. Testing and Validation 

  • Automated Tools: Use tools like WAVE (Web Accessibility Evaluation Tool), Axe, or Lighthouse to identify potential accessibility issues. Remember these tools cannot catch all issues. 
  • Manual Testing:  
  • Keyboard-only navigation: Test all functionality. 
  • Screen reader testing: Test with common screen readers (e.g., NVDA, JAWS, VoiceOver). 
  • Zoom: Test for usability when zoomed up to 200-400%. 
  • Color contrast checks. 
  • User Testing: Involve users with disabilities in testing. 

14. Training and Resources 

  • [Name of Organization] is committed to providing training and resources on accessibility. 
  • Internal Resources: [Link to intranet pages, contact person/department for accessibility questions] 
  • External Resources:  

15. Governance and Updates 

  • This style guide will be reviewed and updated annually, or as needed, to reflect changes in accessibility standards and best practices. 
  • Feedback on this guide is welcome and can be directed to [Contact Person/Department]. 

By adhering to this Design Style Guide, we can collectively ensure that [Name of Organization] is a welcoming and accessible place for all members of our community and beyond. 

Make an investment
in education accessibility

Work with us
Donate to Benetech