Note that while we teach and encourage familiarity with assistive devices, testing with them requires specialized expertise. Although testing for accessibility is helpful at any stage, please request a test before implementing designs, during configuration of vendor solutions, and before launch. Test the contentEnsure the writing is succinct and well organized.Break up long blocks of text into smaller chunks or lists.Check menus, links and headers for clarity.Review your content using the Content Accessibility Checklist.Check your content on a phone to ensure proper scaling.Run automated tests.For sites in the University's SiteBuilder platform, use the built-in accessibility checker.For public-facing sites that are already published, run a test in DubBot.WebAIM's WAVE plug in highlights content errors, offers explanations and suggests fixes. It also makes invisible elements visible (image alt elements, heading structure, etc), so you can see how screen readers interpret the page.Deque's AXE tool works similarly but provides feeback in a linear form, in a separate frame.Test the design & codeUsing WAVE, check the Structure tab: Do the headings form a logical outline, including visually hidden headings for critical non-content elements like the main navigation and search?Are there landmarks for key regions like the banner, navigation(s), main content and footer?In WAVE, check the Contrast tab to manually check colors the tool won't detect:Text on top of image backgroundsHover and focus states on links and buttonsTooltips or validation errors in formsColor choices in charts and graphs, etc.Check your responsive design:Does the theme reflow cleanly down to 320px widths without undue horizontal scrolling, and up to 2560px widths without blurry images or overly long lines?Can the menu and other components be used via touch on a phone?Can users pinch-to-zoom on a phone? Never disable user-scalable.Either install Microsoft Accessibility Insights and run a full assessment, or perform manual keyboard testing: Make sure your browser is configured to enable full keyboard access.Use the Tab key to advance through the page.Every element should clearly change on focus. The cursor change must be obvious.As you Tab, you should be able to reach every link, button and form item, and you should be able to Shift+Tab back through them in reverse. Make sure it works in both directions if elements show and hide on scroll.The order that items are highlighted when tabbing should match the order you read them -- left to right, top to bottom. Exceptions should be rare and logical (e.g., it might make sense for the "close" button in an alert to come after its content, even if it is at the top right).Pages with navigation before the content should have a "skip to main" link -- and clicking it should transfer focus to the content area.Any custom interactive components such as dropdowns, modals and slideshows should also respond to expected key commands, possibly including arrow keys, spacebar, enter and / or esc.If a button causes a modal to appear, focus should be moved into it, and be returned to the button when it closes. And focus should be "trapped" in the modal until the modal is closed, so that the cursor doesn't end up hidden beneath the modal with no way back into it.All this should work on the mobile / responsive design as well; be sure to test both.Request a test with us so we can test your site on our collection of assistive devices.