Policies
-
Why Fillable PDF Forms Are Not Ideal for Accessible and Inclusive Public Documents
City of Bellevue strives to make resources accessible and user-friendly for everyone. While fillable PDF forms have been widely used for data collection, they come with a range of limitations, especially regarding accessibility, accessible technology compatibility, and cross-platform use. This article outlines these concerns and explains why webforms are generally a more effective, accessible choice. 1. Fillable Fields Are Lost When Uploaded to Drupal When fillable PDF forms are uploaded to the Drupal content management system (CMS), their interactivity is lost when viewed on a browser—fillable fields become static and no longer function as intended. Users can only print the form or save a static version, requiring them to complete it manually, which contradicts the intention of providing a fillable document for easy online completion. 2. Adobe Acrobat Pro Dependency Fillable PDFs created in Adobe Acrobat Pro require users to complete them in Adobe Acrobat. Other PDF viewers will not support these as interactive fields. Most users now rely on in-browser PDF rendering or third-party readers, which lack compatibility with Adobe-specific functionality. Additionally, many users don’t have the Adobe plugins required to make these forms work correctly within their browsers. Even when disclaimers are added, we cannot control users’ software choices, and forms often come back incomplete, half-filled, or empty, introducing substantial gaps in data collection. By using fillable PDFs, we place an unintended burden on the public to use specific software—something City of Bellevue should avoid to ensure equitable access. 3. Increased Security, Records, and Accessibility Concerns Fillable PDFs raise security and records management concerns, particularly for sensitive data. When completed, PDFs are often emailed back and forth, raising security risks, including data exposure and potential privacy issues. Additionally, not all fillable PDFs are accessible to users with disabilities, particularly those who rely on screen readers and other assistive technologies. In contrast, a well-designed webform can easily be made accessible and meet required standards, including WCAG compliance. 4. Printed Forms Lead to Handwritten Responses If a fillable PDF form is printed, users will have to complete it by hand, resulting in handwritten responses that may be difficult to read and interpret. This introduces potential inaccuracies and data entry challenges for those processing these forms. Moreover, this increases the risk of user errors and processing delays, especially for information that would be more reliably and legibly captured via an online webform. 5. Signatures Require DocuSign Integration For any PDF form that requires a signature that should hold legal weight, our city policy mandates the use of DocuSign, its approved electronic signature platform. To meet this requirement, having an ITD web team member create a DocuSign-compatible form or webform offers a smoother, streamlined process for both users and administrators. 6. Webforms Offer a More Accessible, Reliable Solution For departments aiming to collect public information, a webform within the CMS offers a better, more accessible solution than a fillable PDF. Webforms are universally accessible across devices, compatible with screen readers, and compliant with accessibility standards. Webforms also provide: Software Flexibility: Webforms can be filled out on any standard browser without requiring specific software, plugins, or downloads. Direct Data Collection: Data is collected directly in the system, eliminating manual data entry and potential errors from handwritten forms. Field Validation: Webforms support required fields, date formats, and other validation checks, ensuring consistent, high-quality data. Security and Records Compliance: With data securely stored within the CMS, webforms provide better data security, privacy, and records management. Given these limitations, departments using fillable PDFs should identify a new business process for data collection. A service request to the ITD web team can initiate the creation of a custom webform tailored to specific needs, ensuring both accessibility and usability for the public. Other acceptable business solutions may also be discussed through a consultation service request. In summary, while fillable PDF forms may appear to simplify data collection, they fall short in terms of accessibility, compatibility, security, and usability. Webforms provide a more accessible, secure, and user-friendly solution, meeting the public’s needs effectively. For assistance or to submit a webform request, please contact the ITD web team.
-
Creating Accessible Excel Spreadsheets
Best Practices for Creating Accessible Excel Spreadsheets 1. Structure Headers: Use clear, descriptive headers for all columns and rows. Avoid merged cells in header rows. Table Design: Use the built-in Table feature (found under the Insert tab) to create structured tables. This enables assistive technologies to recognize and navigate the data. 2. Descriptive Names Sheet Names: Rename worksheets with meaningful names (e.g., "[Program Name] Q1" instead of "Sheet1"). File Names: Follow Records Management file naming conventions and record creation guidance to ensure the record is properly stored for retention and applied with required metadata. 3. Use Alt Text for Visual Elements Visual elements like pictures, shapes, symbols, or icons have accessibility requirements. Images: Add alternative text (Alt Text) to describe images clearly. Right-click the image, select Edit Alt Text, and provide a meaningful description. It should be a description of the image itself and what it is representing. Shapes, Icons, and Illustrations: Similar to images, these require Alt Text. Avoid decorative-only elements unless they serve a clear purpose. If the element is decorative, mark it as “decorative” or “artifact”. Screen readers cannot skip alt text so limiting non-substantive visual elements' alt text is more productive for users requiring screen readers. Symbols (e.g., checkmarks or arrows): Should be avoided. If symbols must be used, a text explanation is still required. Charts: Always include Alt Text for charts, summarizing the data they represent. Use direct labeling and avoid legends if possible. The underlying data should also be presented in a table format for full accessibility. It is acceptable to link to the data in another source or webpage. If hosting the data online on bellevuewa.gov, the data should be stored in PDF format. 4. Use Accessible Formulas Avoid formulas that generate error codes (e.g., #DIV/0!). Use IFERROR to replace errors with user-friendly messages. 5. Use Proper Formatting Font Choices: Refer to the city’s Branding Guidelines for acceptable fonts. Color Contrast: Ensure sufficient contrast between text and background. Tools like the WCAG Color Contrast Checker can help verify compliance. Refer to the city’s Branding Guidelines for acceptable chart and table colors. Print out a chart in black and white to see if there is enough contrast between background and labels. Avoid Color Reliance: Do not rely solely on color to convey information. Include text or symbols as supplementary indicators. Labels: Use direct labeling when possible. Legends are taxing to our working memory. They will be a challenge for people with some cognitive impairments. 6. Handle Comments Thoughtfully Comments and Notes: While Excel allows for adding comments and notes, they are not consistently accessible to screen readers. If critical content is included in comments, integrate it directly into the spreadsheet instead. Conversion to PDF: Comments are not typically preserved as accessible content during PDF conversion. All critical information must be part of the main spreadsheet content. 7. Enable Navigation Features Hyperlinks: Ensure hyperlinks have descriptive text (e.g., "Company Annual Report" instead of "Click Here"). Named Ranges: Use named ranges to help users quickly navigate to specific sections. 8. Run Accessibility Checks Use Excel’s built-in Accessibility Checker (Review tab → Check Accessibility) to identify and fix accessibility issues before sharing the file. When to Use Excel as the Ideal Platform Use Excel for organizing and presenting tabular data that involves calculations, comparisons, or structured analysis. Examples include: Financial reports Data analysis When Not to Use Excel If your content primarily consists of paragraphs of text, graphics-heavy layouts, or narrative storytelling, Excel is not the ideal platform to structure your content. Instead, consider: Microsoft Word: Ideal for reports, letters, or documents requiring long-form text. PowerPoint: Suitable for presentations with visuals and concise bullet points. Design Service Request: For visually complex layouts like multi-page books or other public-facing outreach materials, please submit your request to ITD’s design team to ensure your request meets branding and accessibility requirements. Things to Avoid While Creating the Spreadsheet: Merged Cells: Avoid merging cells, especially in data tables, as they disrupt screen reader navigation. Complex Layouts: Avoid overly complicated designs, such as nested tables or irregular structures. Excessive Blank Cells: Avoid large gaps of blank rows or columns, as they confuse assistive technologies. Relying on Visuals: Do not reference pictures, shapes, or symbols without descriptive text. When Converting to PDF: Skipping Tags: Ensure accessibility tags are enabled during PDF conversion. Go to File → Save As → PDF, then check "Options" and select "Document structure tags for accessibility." Flattened PDFs: Avoid saving the PDF in a way that rasterizes text (e.g., as an image-only PDF), which makes it unreadable by screen readers. Untested PDFs: Test the converted PDF using an alternate PDF viewer tool. Re-test your PDF using another tools accessibility features (e.g. Adobe Acrobat’s Accessibility Checker) to ensure compliance. When publishing charts/graphs online: Do not post graphs, charts, or tables as an image from your excel spreadsheet online. Any image cannot have flat text to be accessible. Text should be actual, selectable text. Instead, rebuild your table, chart, graph in Drupal using the available option under paragraph type.
-
Creating Accessible PDFs
Best Practices for Creating Accessible PDFs 1. Use Source Files That Are Already Accessible Create your original file (Word, Excel, PowerPoint, etc.) with accessibility in mind. Follow platform-specific accessibility guidelines to ensure proper structure, Alt Text, and formatting. Edits should be made to the source file, not the PDF. Do not use Acrobat’s editing tools to change text and images in the PDF. Include proper heading structures, clear navigation, and descriptive Alt Text in the source file before converting to PDF. 2. Use Tags to Structure Content Tags define the structure of a PDF, enabling screen readers to navigate the content effectively. During conversion, ensure the "Document structure tags for accessibility" option is enabled. Open the tags pane to edit the tags appropriately. 3. Add Alternative Text (Alt Text) Images, Graphics, and Charts: Provide Alt Text for all visual elements. If the element is decorative, mark it as “decorative” or “artifact”. Screen readers cannot skip alt text so limiting non-substantive visual elements' alt text is more productive for users requiring screen readers. Use Adobe Acrobat’s Tags pane or Accessibility Tools to add or edit Alt Text for any images missing descriptions. 4. Ensure Logical Reading Order Verify that the reading order is logical and flows naturally from top to bottom, left to right. In Adobe Acrobat Pro, use the Reading Order tool to adjust the sequence of content if necessary. 5. Use Proper Document Properties Add descriptive metadata to your PDF: Go to File → Properties → Description. Include a clear title, author, subject, and keywords. Specify the document language: Go to File → Properties → Advanced → Language. 6. Provide Descriptive Hyperlinks Hyperlinks should have meaningful text (e.g., "Visit the Accessibility Guide" instead of "Click Here"). Ensure links are functional and easy to distinguish from the surrounding text. 7. Use Recommended Fonts, Colors, and Layout Refer to the city’s Branding Guidelines for appropriate fonts. Refer to the city’s Branding Guidelines for appropriate colors when your file will not be displayed in black and white. Color cannot be used to convey meaning alone; use text labels as well. 8. Test the PDF for Accessibility Use your PDF reader’s built-in accessibility tools (e.g. Adobe Acrobat’s built-in Accessibility Checker): Example: Go to Tools → Accessibility and select Full Check. Fix identified issues using the recommended tools within Acrobat. Every time PDF is adjusted, in-app Accessibility check and fixes need to be repeated. Things to Avoid When Creating PDFs: Unstructured Scans: Avoid creating PDFs from scanned images without Optical Character Recognition (OCR). Use OCR tools to convert scanned text into selectable and searchable content. Flattened PDFs: Avoid flattening the document (e.g., saving as an image-only PDF), as it makes the text unreadable by assistive technologies. Complex Layouts: Avoid irregular or complex layouts, such as multiple columns without clear headings or inconsistent formatting. Breaking Tables Across Pages: Tables and sectioned content should not be broken across pages. It is identified as a separate tables or paragraph tags requiring more complex tagging if headers aren’t labeled properly. Improperly Expressing Content: Reserve tables for presenting numerical data. Structure content in list format. Do not present information in containers: They are visually unnecessary and are identified as figures by accessibility tools which requires manual correction. When Converting From Another Platform: Skipping Tags During Conversion: Ensure accessibility tags are enabled in the export settings of Word, Excel, or PowerPoint before saving as PDF. Decorative Elements Without Marking Them: Don’t leave decorative images or visual elements unmarked. Indicate them as "decorative" in the tags to avoid confusion for screen readers. Relying on Embedded Styles Alone: Ensure styles, such as headings, lists, and tables, are properly tagged after conversion. Flattened Text Over Images: Any image cannot have flat text to be accessible. If you are uploading an image into your PDF, do not have text overlayed on your image. Add text to alt text descriptions, as a caption, or in the main body of your PDF.
-
Creating Accessible Presentations
Best Practices for Creating Accessible PowerPoint Presentations 1. Use Slide Templates or Layouts For external-facing or internal-facing presentations, use pre-built presentation templates available for download in Image Relay. These templates are on-brand and structured to be accessible. All CoB public-facing materials should follow the city’s Branding Guidelines. For internal-facing presentations only, the use of built-in slide layouts is also available in the Home tab. These layouts are structured to be accessible and help screen readers navigate slide content logically. Avoid manually placing text boxes or objects outside of the designated layout areas. 2. Add Alt Text to Visual Elements Images, Graphics, and Shapes: Right-click on the element, select Edit Alt Text, and provide a concise description of what is presented and what it is portraying. If the element is decorative, mark it as “decorative” or “artifact”. Screen readers cannot skip alt text so limiting non-substantive visual elements' alt text is more productive for users requiring screen readers. Charts and Graphs: Provide Alt Text summarizing the key information. Also, ensure the underlying data is available in a table, included in the speaker notes, or can be linked to in another source. 3. Provide Descriptive Hyperlinks Use descriptive hyperlink text, such as "Visit the Accessibility Guide" instead of "Click Here." Test all hyperlinks to ensure they work correctly. 4. Use Simple, Clear Content Keep text concise and use bullet points for readability. Avoid overly complex graphics. Simplify charts and diagrams where possible. 5. Include Speaker Notes Add key details or alternative descriptions in the Speaker Notes section to support users who may rely on assistive technologies. 6. Enable Logical Reading Order Use the Arrange → Selection Pane tool in the Home tab to check and adjust the reading order of slide elements. Screen readers read content in the order it appears in the Selection Pane. 7. Use Accessibility Checker Use PowerPoint’s built-in Accessibility Checker (Review tab → Check Accessibility) to identify and resolve accessibility issues. Things to Avoid While Creating the Presentation: Custom Layouts: Avoid creating custom slide layouts without ensuring they are on-brand or accessible. Overlapping Content: Avoid overlapping text boxes or images, as this can disrupt screen readers. Color-Only Indicators: Don’t use color alone to convey meaning (e.g., red text for "bad" or green for "good"). Add text labels or symbols. Overloaded Slides: Avoid too much information or graphics onto a single slide. Use the same font size for slide body content throughout. When Converting to PDF: Skipping Tags: Ensure that the PDF retains accessibility tags during conversion: Go to File → Save As → PDF, then click Options and ensure "Document structure tags for accessibility" is checked. Flattened PDFs: Avoid exporting to a flattened PDF (image-only format), which makes the content unreadable for screen readers. Any image cannot have flat text to be accessible. If you are uploading an image into your presentation and plan to convert it to a PDF, do not have text overlayed on your image. Add text to alt text descriptions, as a caption, in the speaker notes, or in the main body of your presentation. Loss of Alt Text: Double-check that Alt Text for images and graphics remains intact after conversion. Unverified PDF: Always re-test the converted PDF using the PDF reader’s accessibility tool (e.g. Adobe Acrobat’s Accessibility Checker.) Additional Recommendations Avoid Animations and Transitions: Avoid excessive animations or transitions, as they can distract users or cause issues for those with sensory sensitivities. Provide a Text-Only Version: Consider offering a text-only version of the presentation for users who may prefer a simpler format. Submit a Design Service Request: When in doubt, submit a design service request to ensure your public-facing presentation is on-brand and accessible, and ready for publication online.
-
Creating Accessible Word Documents
Best Practices for Creating Accessible Word Documents 1. Use Proper Document Structure Headings: Use built-in heading styles (Heading 1, Heading 2, etc.) to create a logical structure. These can be found in the Home tab under the Styles group. Lists: Use Word's built-in numbered or bulleted list functions instead of manually formatting lists. Tables: Avoid tables if possible. If required, use simple table structures. Include a clear header row by selecting "Repeat Header Row" under the Table Tools → Layout tab. Tables require proper tagging annotations. 2. Add Alt Text for Visual Elements Images, Graphics, and Shapes: Right-click the element, choose Edit Alt Text, and provide a brief description of its purpose or content. If the element is decorative, mark it as “decorative” or “artifact”. Screen readers cannot skip alt text so limiting non-substantive visual elements' alt text is more productive for users requiring screen readers. Charts and Diagrams: Add Alt Text to describe the data or content visually presented. If the chart contains critical data, ensure the data is also provided in the document text or as a properly structured table. 3. Ensure Readability Fonts: Use the city’s Branding Guidelines for the appropriate Heading (Montserrat) and body (Open Sans) sans-serif fonts. Use recommended font size. Color Contrast: Use the city’s Branding Guidelines for selecting brand colors and backgrounds to ensure sufficient contrast. Avoid Color Reliance: Do not rely solely on color to convey meaning, like in a legend. Add text labels or symbols as other indicators. Backgrounds: Avoid textured backgrounds behind text. Use flat color with proper contrast when needed. 4. Add Descriptive Hyperlinks Use meaningful hyperlink text (e.g., "Visit the Accessibility Guide" instead of "Click Here"). Add a brief description of the link destination if necessary. 5. Use the Accessibility Checker Use Word’s built-in Accessibility Checker: Review tab → Check Accessibility. Follow the suggestions to fix any issues. 6. Include Descriptive Metadata Set descriptive document properties: Go to File → Info and fill out the title, author, subject, and keywords. Things to Avoid While Creating the Document: Text Boxes: Avoid using text boxes; they will not read correctly by screen readers. Use pre-built styles for layout instead. Complex Tables: Avoid merged or split cells in tables, as these can disrupt screen reader navigation. Unstructured Formatting: Avoid using bold or enlarged font sizes for headings. Use the built-in heading styles instead. Blank Spaces for Layout: Don’t use multiple spaces, tabs, or empty paragraphs for alignment or spacing. Use paragraph spacing and alignment tools instead. Use Templates: The design team has created several pre-built templates for employees to download and use as a starter for your document. When Converting to PDF: Skipping Accessibility Tags: Ensure the document is converted with accessibility tags. In Word, use File → Save As → PDF, then click Options and ensure "Document structure tags for accessibility" is checked. Flattening Text: Avoid saving the PDF as an image-only file, as it renders text unreadable by assistive technologies. Any image cannot have flat text to be accessible. If you are uploading an image into your PDF, do not have text overlayed on your image. Add text to alt text descriptions, as a caption, or in the main body of your PDF. Untested PDF: Don’t assume the PDF is accessible. Re-test your PDF using another PDF reader’s accessibility tools (e.g. Adobe Acrobat’s Accessibility Checker) to validate the file. Additional Recommendations for Accessibility Use Descriptive Captions: For any referenced tables, charts, and images, include captions to provide context. Avoid Overly Graphic-Heavy Layouts: Balance graphics and text to maintain readability and navigability. Maintain Logical Reading Order: Ensure the content flows naturally from top to bottom, left to right. Submit a Design Request: When in doubt, submit an ITD design request to ensure your public-facing Document meets branding and accessibility guidelines.
-
Creating Named Ranges in Excel
Simplify navigation and improve the usability of Excel spreadsheets by creating named ranges. Named ranges allow you to assign a descriptive name to a cell or range of cells, making it easier to reference them in formulas. Creating Named Ranges 1. Using the Name Box Select the Cell or Range: Click and drag to highlight the cell(s) you want to name. Enter the Name: Look for the Name Box in the top-left corner, next to the formula bar. Click inside the Name Box, type the name you want and press Enter. The name is now assigned to that range. 2. Using the Define Name Dialog Select the Cell or Range: Highlight the cell(s) you want to name. Open the Define Name Dialog: Go to the Formulas tab on the ribbon. Click Define Name in the Defined Names group. Define the Name: In the pop-up dialog box: Enter the Name (e.g., "Q1-Program-Results"). Ensure the Scope is set (workbook by default, or a specific worksheet). The Refers to field should automatically populate with the selected range. If not, you can manually type the range (e.g., =Q1-Program-Results!$A$1:$A$10). Click OK. 3. Automatically Create Named Ranges for Multiple Headings Select the Data Range: Highlight the table that includes column or row headers and the associated data. Open the Create from Selection Dialog: Go to the Formulas tab → Click Create from Selection. Select Naming Options: Choose whether to use the Top Row, Left Column, Bottom Row, or Right Column as the basis for the range names. Click OK. Excel will automatically create named ranges for each header and its associated data. Managing Named Ranges You can edit, delete, or review named ranges using the Name Manager: Go to the Formulas tab. Click Name Manager in the Defined Names group. In the Name Manager dialog: Select a named range to Edit, Delete, or Filter. Double-click a name to update its range or properties. Using Named Ranges 1. In Formulas: Instead of referencing cells directly (e.g., =SUM(A1:A10)), you can use the named range (e.g., =SUM(SalesData)). 2. For Navigation: Click the Name Box, select the named range from the dropdown, and Excel will take you to that range. Best Practices for Named Ranges Use meaningful, descriptive names (e.g., "EmployeeSalaries" instead of "Range1"). Avoid spaces in names; use hyphens, underscores or camel case instead (e.g., “Total-Participants”, "Total_Participants" or "TotalParticipants"). Keep names short but clear to improve readability. Regularly review and clean up unused named ranges in the Name Manager. By following these steps, you can enhance your spreadsheet's functionality and make it more accessible to users, including those who rely on assistive technologies.
-
ADA Title II WCAG 2.1 AA Requirements for Web and Mobile Content
Conformance Requirements: To meet WCAG 2.1 Level AA, city websites, digital files, and subscribed services must follow all Level A and Level AA rules, including new ones added in WCAG 2.1. WCAG 2.1 works with WCAG 2.0, so if you meet 2.1 standards, you also meet 2.0. WCAG 2.1 Changes: WCAG 2.1 adds 17 new rules to improve accessibility for mobile devices, low vision users, and experiences for users with cognitive disabilities making content easier to use without changing WCAG 2.0 standards. Some Key Standards for WCAG 2.0 AA: Keyboard Navigation: All features must work with a keyboard. Color Contrast: Text and background colors must be easy to read with a minimum contrast ratio of 4.5:1 for normal text. Resizable Text: Users must be able to resize text up to 200% without losing content or function. Navigable Content: Users must be able to navigate and determine the user location on a page. Labels and Instructions: Forms and controls must have clear labels and instructions. Error Identification: Users must be alerted about errors with clear instructions to fix them. Note: These standards are not inclusive. A full list of WCAG 2.0 AA standards may be referenced on W3C’s website. New Standards in WCAG 2.1 AA: Orientation: Content must work in portrait and landscape modes. Input Purpose: Fields collecting user info must be labeled for easier autofill. Responsiveness: Content should work well on small screens (like phones). Non-Text Contrast: Buttons and controls must also meet contrast requirements of a 3:1 ratio. Text Spacing: Users can change text spacing without breaking the design. Hover or Focus Content: Pop-ups or tooltips must be easy to dismiss or interact with. Keyboard Shortcuts: Users can turn off or adjust single-key shortcuts. Pointer Gestures: Complex gestures (like two-finger swipes) must have simple alternatives. Pointer Cancellation: Actions triggered by touch can be stopped or undone. Label in Name: Visible labels should match what assistive tech announces. Motion Controls: Features triggered by shaking or tilting must have another option (like changing the orientation of the content from portrait to landscape on a phone). Status Messages: Updates (like form submissions) should notify users without disrupting their application flow. Content Owner Responsibility Content Audit and Remediation Identification: Accessibility and Quality Assurance Reports: Make use of available reports (e.g. Site Improve) to identify and prioritize efforts. Clear Headings and Labels: Use a logical heading structure (H1, H2, H3) to organize content; all files and websites must use hierarchy in order (cannot create H4 before the creation of H2 or H3). Buttons, links, and form fields must be identified by the appropriate type and annotated. Webpages should support this without intervention. PDFs may require manual correction if the file was not correctly structured. Assessing Navigation Aids: Validate search helps users find specific content by identifying key words and forced page results. We already display breadcrumb navigation to show users their location on our website; simplify the sitemap to reduce child pages. Ideally, our information architecture should be fewer than 4 levels. Descriptive Link Text: Use meaningful link text (e.g., "Read More About Accessibility" instead of "Click Here"). Accessible Forms: Group related fields together and use labels and instructions to guide users. Simplify PDF forms when possible and understand that fillable forms are not supported. Use a webform when possible to support accessibility and record retention. Logical Tab Order: Arrange interactive elements in a logical order so users can navigate efficiently using the Tab key. Tab Order is Header, Main Body, Sidebar, Footer. Follow recommended guidance for how to structure the main content/sidebar paragraph types, which publishers and/or content authors can control. Make use of the Branding Guidelines: Digital content should follow the latest version of branding guidelines which provide details on how to structure content correctly for public outreach. Document Compliance: Record pages that meet conformance and those requiring fixing. Site Improve reports should show a fewer number of flagged page results. PDF files will have to be performed manually. Remove files from the CMS that are not necessary. Ensure proper records retention for source file management beyond the 2 year website retention period. Update files that need to remain hosted on the public website, ensuring WCAG 2.1 AA compliance. Follow the updated file naming convention and mirror the file name in e-records to support future file reconciliation. Note any exceptions with justification. Content Updates: Test new pages, features, or updates before publishing. Note: the Web Team will implement Site Improve Pre-publish for more proactive accessibility validation. Information Technology Responsibility Web Team and Developer Testing and Remediation Identification Keyboard Navigation Testing: Use of Tab, Shift + Tab, and Enter keys navigate through the site. Interactive elements are accessible and follow a logical sequence. Keyboard Accessibility: Visible focus indicators (e.g., outlines) navigate appropriately with a keyboard. For links or buttons in a PDF, highlight effect activates when selected using the keyboard Link text changes color when tabbed into. PDF is tagged for accessibility and read back appropriately with use of a screen reader tool. Consistent Navigation: Consistent menus and layouts across all pages to promote consistent navigation patterns. For subscription services, recommend a consistent menu approach if possible to support. Responsive Design: Optimize navigation for all devices, ensuring menus and content are accessible on small screens. Screen Reader Testing: Use web-based developer tools (e.g. WAVE) to highlight accessibility issues like navigation and color contrast to outline remediation requirements. Use web-based user experience tools(e.g. NVDA) for testing different visual impairments to identify improvements. Note: This would be ideally performed by a contracted and certified tester or service. Mobile Testing: Test navigation on different mobile devices to ensure menus, buttons, and links are accessible and responsive. Focus Indicators Check: Verify that a visible focus indicator appears when navigating via keyboard like link text highlighting. Real User Research Testing: If possible, conduct research to verify keyboard-only or screen reader users are able to navigate the site and provide their feedback. Logical Tab Order Verification: Test the navigation order using the Tab key to ensure users move through elements logically. Ideal Testing ITD public website and app development teams will conduct platform and website testing for functional performance of accessibility requirements. If budget allows, additional contracted services can support testing and auditing services to support remediation and conformance requirements. 1. Preparation Testing Tools: Accessibility Evaluation Tools: WAVE, Site Improve Screen Readers: NVDA Mobile and Tablet Devices (iOS, Android) Testing Scope: Test all pages (e.g., homepage, forms, media files, dynamic content). Include variations such as desktop, mobile, and tablet views. Success Criteria: WCAG 2.1 AA success criteria are tested (see standards list below). 2. Testing Steps Automated Testing: Run automated tests using Site Improve and/or WAVE on all pages. Keyboard Accessibility Testing Navigate the entire site using only a keyboard (Tab, Shift + Tab, Enter, Esc) and verify: Logical order Visible focus indicators All interactive elements (links, buttons, menus) are accessible. Screen Reader Testing Contract with a certified tester or service to validate content within webpages, files, and applications have: Proper reading order Accurate, meaningful image alt text (different that using a tool to confirm the presence of alt text) Descriptive labels for forms and controls Clear announcements for status messages and error alerts Responsive and Mobile Testing Test sites, applications, and digital files on different devices and screen sizes. Verify content reflows or is responsive without losing functionality (e.g., menus, forms). Media and Forms Testing Test video and audio content for captions, transcripts, and audio descriptions; animated GIFs or other media representations must also be assessed for anti-seizure requirements. Media file owners should be contacted to remove unnecessary media files that cause a potential risk, or replace the media file with a more appropriate alternative. Verify form fields: Have clear labels Support autofill for input purposes (e.g., name, address) Provide error notifications that are perceivable to all users 3. Evaluation and Documentation Report Issues: Categorize issues by severity (critical, moderate, low). Determine appropriate team or content owner to remediate issue. Re-Test After Fixes: Re-run automated and manual tests on updated content to confirm fixes. 4. Ongoing Monitoring Regular Audits: Schedule periodic accessibility audits (e.g., quarterly). Resources WCAG 2.0 AA Guidelines: https://www.w3.org/TR/WCAG20/#wcag-2-layers-of-guidance WCAG 2.1 AA Guidelines: https://www.w3.org/TR/2023/REC-WCAG21-20230921/
-
Converting Drawings to Accessible Images
Architectural drawings, engineering schematics, and other technical illustrations often contain handwritten annotations and complex visuals that make them difficult to interpret for individuals with disabilities. To comply with WCAG 2.1 AA, Section 508, and Title II of the ADA, drawings posted on bellevuewa.gov or related government websites must be accessible to all users, including those who rely on assistive technologies. This guide outlines the key accessibility concerns associated with digital drawings and provides best practices for converting them into accessible formats. Common Accessibility Issues in Drawings 1. Handwritten Annotations Are Difficult to Read Issue: Handwritten notes may lack clarity, making them inaccessible to users with low vision or cognitive impairments. Solution: Convert all handwritten annotations into typed text labels with a minimum contrast ratio of 4.5:1 for standard text and 3:1 for large text. 2. Screen Readers Cannot Interpret Image-Only Content Issue: Static image files (e.g., scanned PDFs, JPEGs, PNGs) do not contain machine-readable text, preventing screen readers from conveying the information. Solution: Provide a text-based summary of the drawing, outlining essential details in a structured format. 3. Missing Alternative Formats for Data Representation Issue: Numeric values, such as slopes, dimensions, and measurements, are often embedded in the image and not provided elsewhere. Solution: Include a data table summarizing key measurements and calculations in an accessible format. 4. Poor File Format and Structure Issue: Posting drawings as unstructured PDFs or rasterized images limits accessibility. Solution: Ensure that PDFs are tagged for screen readers, or use web supported image files (currently .png or .jpeg) with properly labeled elements when embedding this as media on a webpage. How to Convert Drawings to an Accessible Format Step 1: Convert Handwritten Annotations to Text Use digital text for all labels and notes. Ensure proper contrast between text and background. Reference the city's Branding and Style Guidelines document, and use Open Sans (a sans-serif font) for better readability. Step 2: Provide a Text-Based Description Include a detailed summary of the drawing’s key components within the pdf and when labeling the image, or when referencing the image within the webpage's body copy. Outline relevant details in compliance with applicable regulations (e.g. Washington building codes, etc.). Step 3: Create an Alternative Data Table If the drawing contains numeric values, provide a structured table summarizing: Measurements (e.g., angles, distances, area calculations). Compliance thresholds for regulatory standards. Structured tables include labeled headers. Step 4: Choose an Accessible File Format If using a PDF: Ensure that it is tagged and follows accessibility best practices. To tag PDFs, use Adobe Acrobat's Accessibility Tools, or alternative PDF tool's (e.g. Bluebeam) document features to tag PDF elements properly. If embedding the drawing as an image on a webpage: Label elements with alt text and provide captions for better compatibility with assistive technologies. Example: Before and After Accessibility Improvements Accessibility Issue Original State Improved State Handwritten Annotations Notes are handwritten and hard to read. Text is digitally typed with proper contrast. Lack of Screen Reader Support Drawing is a static image with no text alternative. A full text-based description is provided. Missing Numeric Data in Text Form Measurements are embedded in the image. A separate data table is included. Inaccessible File Format Scanned PDF without proper tagging. Tagged PDF or image files with labeled elements, alt text, and captions. Why This Matters By implementing these changes, drawings posted as PDFs or Images on bellevuewa.gov are in compliance with ADA Title II WCAG 2.1 AA guidelines while improving accessibility for all users. These updates benefit: Individuals with visual impairments using screen readers. Users with cognitive disabilities who need clear, structured text. General audiences who may struggle with poor contrast or handwriting. Making drawings accessible enhances public engagement and ensures that all citizens can access critical planning information equitably. For more guidance on accessibility compliance, refer to our other accessible resource articles in IT's knowledge base.