Skip to main content

HTML

ARIA 1.2 specification, WCAG 2.2 specification, Switch Control, Voice Control, Invert Colors, Speak Screen, and Reduce Motion

  1. Accessibility (A11y) & HTML Structure:
    • Tables: Several tables are missing <thead> elements or scope attributes on row headers (<td>), which impacts screen reader usability.
      • Files: former-students-today.component.html, courses.component.html, about.component.html, past-roles.component.html.
      • Recommendation: Add scope="row" to the first <td> in each <tr> within <tbody> where it acts as a row header.
    • Incomplete Tables: Some tables seem incomplete, lacking <tbody> or any data rows.
      • Files: grad-thesis.component.html, chairperson.component.html.
      • Recommendation: These tables need to be populated with data or completed structurally. I'll add comments indicating this.
    • Carousel Keyboard Navigation: The carousel in former-students-today.component.ts explicitly disables keyboard navigation (config.keyboard = false), which is detrimental to accessibility.
      • Recommendation: Enable keyboard navigation by setting config.keyboard = true.
    • Image Alt Text: Alt text is generally present and often uses data binding. Ensure the bound data (award.award, job.title, p.org, etc.) provides meaningful descriptions. The use of specific altTagMetadata fields in awards.component.html is a good practice.
    • Focus Management: The header component includes :focus-visible styles, which is good. Ensure modals (NgbModal) handle focus trapping correctly (ng-bootstrap usually does this well).
    • Semantic HTML: Use of <section>, <h4>, etc., seems appropriate. <caption> is used correctly in grad-thesis.component.html and courses.component.html.
    • Video Autoplay: The video in courses.component.html autoplays. While muted, autoplay can still be distracting. Consider adding explicit play/pause controls, especially if the video is long or contains important information. For now, the title attribute is present.
    • iFrames: iFrames in chairperson.component.html and awards.component.html have title attributes. Good.

aria-labelledby​

1. Complex form controls:

  • Consider a custom component that combines an input field and a label element that appears visually hidden. The input field might have an ID like registration-email, and the label element (containing text like "Email Address") would have the id attribute set to registration-email-label. The input field would then use aria-labelledby="registration-email-label" to associate the hidden label text with the input field for screen readers.

2. Dynamic content:

  • Imagine a tabbed interface where the tab buttons and content panels are dynamically generated by JavaScript. Each tab button could have an ID like tab-button-1, tab-button-2, etc. The corresponding content panel would then use aria-labelledby="tab-button-1" to link it to the appropriate tab button. This ensures screen readers announce the tab title when the user navigates to the content panel.

3. Rich widgets:

  • Custom UI elements like date pickers or color pickers might leverage aria-labelledby for accessibility. The widget itself could have an ID, and separate elements within the widget that provide labels or instructions would use aria-labelledby to connect them.

4. ARIA live regions:

  • When using live regions to announce dynamic content updates, you can leverage aria-labelledby to associate the live region with a descriptive title element. This clarifies the purpose of the announced content for screen reader users.

Key points to remember:

  • Use aria-labelledby when the visible label isn't directly associated with the element in the HTML structure.
  • It's ideal for situations where the label is hidden visually or programmatically generated.
  • The element referenced by aria-labelledby should have a unique ID and clear descriptive text.

By combining IDs and aria-labelledby, you ensure that interactive elements and dynamic content have proper labels for screen reader users, improving the overall accessibility of your web application.

Web Accessibility Audits using assistive and automated technologies

  • WAVE from WebAIM
  • Level Access
    • Access Assistant
    • Accessibility Management Platform (AMP)
  • JAWS
  • NVDA
  • ZoomText
  • Dragon Naturally Speaking
  • Adobe Acrobat
  • Microsoft Accessibility Checker

Accessibility Audits against Digital Documents (e.g., PDF, Word, etc…)

> Section 508 and Web Accessibility Initiative (WAI) guidelines and specifications–W3C Web Content Accessibility Guidelines (WCAG 2.0 A and AA), Accessible Rich Internet Applications (ARIA), User Agent Accessibility Guidelines (UAAG), and Authoring Tool Accessibility Guidelines (ATAG)

Certification

https://www.wix.com/learn/certification/accessibility

deque.com/axe-con

To ensure that horizontal scrolling is accessible for users with disabilities, consider the following guidelines:

  1. Keyboard Accessibility: Ensure that users can navigate and interact with horizontally scrollable content using only the keyboard. This includes allowing users to focus on the scrollable content, scroll horizontally, and access any interactive elements within the content using keyboard controls such as arrow keys, Tab, Shift+Tab, and Enter or Spacebar for activation.

  2. Focus Management: Ensure that the focus indicator is clearly visible and appropriately styled for users who navigate using the keyboard. When users scroll horizontally, the focus should remain on the currently focused element or move to the next logical element in the scrollable content.

  3. Screen Reader Compatibility: Test the horizontal scrolling behavior with screen readers to ensure that the content and interactions are properly conveyed. The screen reader should announce the presence of horizontally scrollable content and provide users with clear instructions on how to access and interact with it.

  4. ARIA Roles and Attributes: Use appropriate ARIA (Accessible Rich Internet Applications) roles and attributes to enhance the accessibility of horizontally scrollable content. For example, you can use the role="scrollbar" attribute to indicate that an element is a scrollbar and provide the associated ARIA attributes like aria-orientation and aria-valuemax, aria-valuemin, and aria-valuenow to describe the scrollable range and current scroll position.

  5. Alternative Navigation Options: Provide alternative navigation options for users who may have difficulty with horizontal scrolling. This can include implementing buttons or links that allow users to jump directly to specific sections or using a collapsible/accordion-style layout to present the content in a more vertically oriented format.

  6. Assistive Technology Testing: Test the horizontal scrolling implementation with a variety of assistive technologies, including screen readers and keyboard navigation tools, to ensure compatibility and usability.

  7. Documentation and Instructions: Provide clear and concise instructions or documentation explaining how to navigate and interact with the horizontally scrollable content. Include information on the available keyboard controls and any alternative navigation options.

By following these guidelines, you can help ensure that users with disabilities can access and interact with horizontally scrollable content effectively and have a positive user experience.

Testing the compatibility and usability of horizontal scrolling with assistive technologies involves evaluating how well users with disabilities can access and interact with the content. Here are some methods to test the compatibility and usability:

  1. Screen Reader Testing: Use screen readers such as JAWS, NVDA (NonVisual Desktop Access), or VoiceOver (on macOS and iOS) to navigate and interact with the horizontally scrollable content. Pay attention to how the screen reader announces the presence of horizontally scrollable content, whether it provides clear instructions on how to access and navigate it, and how it conveys any interactive elements within the content.

  2. Keyboard Navigation Testing: Disable the mouse or trackpad and use only the keyboard to navigate and interact with the horizontally scrollable content. Test if you can reach and focus on the scrollable content using keyboard controls like Tab, Shift+Tab, and arrow keys. Verify if the focus indicator is visible and properly styled. Test if you can scroll horizontally using the keyboard and navigate to interactive elements within the content.

  3. Assistive Technology Simulators: Utilize browser extensions or tools that simulate the behavior of specific assistive technologies. For example, the Web Developer Toolbar extension for Firefox has an Accessibility menu that allows you to simulate various disabilities and test the compatibility of your horizontal scrolling implementation.

  4. User Testing: Conduct user testing sessions with individuals who use assistive technologies. Observe how they interact with the horizontally scrollable content, identify any difficulties or barriers they encounter, and gather feedback on the overall usability and accessibility of the scrolling experience. This feedback can help identify areas for improvement and inform any necessary adjustments to the design.

  5. Accessibility Guidelines: Refer to accessibility guidelines and standards such as the Web Content Accessibility Guidelines (WCAG) to ensure that your horizontal scrolling implementation meets the recommended accessibility criteria. These guidelines provide specific criteria and success criteria related to keyboard accessibility, screen reader compatibility, and other aspects of accessibility that can be used as a basis for testing.

Remember, testing with real users who rely on assistive technologies is crucial to gaining insights into the actual user experience. It's essential to involve users with disabilities throughout the design and development process to ensure that the horizontal scrolling is accessible and usable for everyone.

Best Practices for Optimizing Web Applications for Accessibility​

To ensure your web application is accessible to users with disabilities—including those who rely on screen readers or have mobility impairments—follow these best practices:

1. Use Semantic HTML​

  • Use native HTML elements (e.g., <button>, <nav>, <main>, <header>, <footer>, <form>, <label>, <input>) to convey structure and meaning.

  • Organize content with headings (<h1>–<h6>) in a logical hierarchy.

2. Provide Text Alternatives​

  • Add descriptive alt text to all images and icons.

  • Use captions and transcripts for audio and video content.

3. Ensure Keyboard Accessibility​

  • Make all interactive elements (buttons, links, forms, menus) operable via keyboard (Tab, Shift+Tab, Enter, Space, Arrow keys).

  • Avoid removing focus outlines; use :focus-visible for custom styling.

  • Use tabindex="0" for custom components that should be focusable.

4. Manage Focus Effectively​

  • Set focus programmatically when opening dialogs, modals, or dynamic content.

  • Use focus trap techniques for overlays and dialogs.

5. Use ARIA Roles and Attributes Appropriately​

  • Use ARIA roles and attributes only when native HTML is insufficient.

  • Ensure ARIA labels, roles, and properties are accurate and descriptive.

6. Color and Contrast​

  • Ensure text and interactive elements meet WCAG AA contrast ratios (at least 4.5:1).

  • Do not use color as the only means of conveying information.

7. Accessible Forms​

  • Associate <label> elements with form controls using for and id.

  • Provide clear, accessible error messages and validation feedback.

8. Responsive and Flexible Layouts​

  • Design layouts that adapt to different screen sizes and zoom levels.

  • Avoid fixed heights/widths that can cause content to be clipped or hidden.

  • Add skip navigation links for keyboard users (e.g., "Skip to main content").

  • Use landmarks (<main>, <nav>, <aside>, <footer>) for easier navigation.

10. Test with Assistive Technologies​

  • Use screen readers (JAWS, NVDA, VoiceOver), keyboard navigation, and automated tools (axe, WAVE) to test accessibility.

  • Involve users with disabilities in usability testing.

11. Avoid Time-Based or Motion-Dependent Interactions​

  • Provide alternatives for interactions that rely on timing or gestures.

  • Allow users to pause, stop, or adjust moving, blinking, or scrolling content.

12. Documentation and Instructions​

  • Provide clear instructions for using custom widgets or complex interactions.

  • Document available keyboard shortcuts and alternative navigation options.

References: