Convert Figma logo to code with AI

w3c logoaria-practices

WAI-ARIA Authoring Practices Guide (APG)

1,284
414
1,284
665
View on GitHub

Top Related Projects

a11yproject's avatar

a11yproject.com

3,827

The A11Y Project is a community-driven effort to make digital accessibility easier.

w3c's avatar

wcag

1,292

Web Content Accessibility Guidelines

Quick Overview

The w3c/aria-practices repository is a comprehensive resource for developers implementing accessible web interfaces. It provides detailed guidance on using ARIA (Accessible Rich Internet Applications) to enhance the accessibility of web content and applications. The repository includes authoring practices, examples, and patterns for creating accessible user interface components.

Pros

  • Offers extensive documentation and best practices for implementing accessible web components
  • Provides working examples and code patterns for various UI elements
  • Regularly updated to reflect the latest ARIA specifications and accessibility guidelines
  • Maintained by the W3C, ensuring high-quality and authoritative content

Cons

  • Can be overwhelming for beginners due to the extensive amount of information
  • Some examples may require additional styling or functionality for production use
  • Focuses primarily on ARIA and may not cover all aspects of web accessibility
  • Implementation of some patterns may require significant development effort

Code Examples

This repository is not a code library but rather a collection of guidelines and examples. Therefore, we'll skip the code examples section.

Getting Started

As this is not a code library, there are no specific installation or setup instructions. However, to get started with using the ARIA practices:

  1. Visit the repository: https://github.com/w3c/aria-practices
  2. Browse the "practices" directory for specific component guidelines
  3. Explore the "examples" directory for working demonstrations
  4. Refer to the "aria-practices.html" file for an overview of ARIA authoring practices

To contribute or report issues:

  1. Fork the repository
  2. Make your changes or additions
  3. Submit a pull request with a clear description of your modifications

For more information on contributing, refer to the CONTRIBUTING.md file in the repository.

Competitor Comparisons

a11yproject logo

a11yproject.com

3,827

The A11Y Project is a community-driven effort to make digital accessibility easier.

Pros of a11yproject.com

  • More user-friendly and accessible content for beginners
  • Broader coverage of accessibility topics beyond ARIA
  • Active community contributions and regular updates

Cons of a11yproject.com

  • Less technical depth compared to aria-practices
  • Fewer code examples and practical implementations
  • Not an official W3C recommendation

Code Comparison

aria-practices example (ARIA Authoring Practices):

<button aria-pressed="false" onclick="toggleButton(event)">
  <svg aria-hidden="true" width="16" height="16">
    <use xlink:href="#icon-thumb"></use>
  </svg>
  Like
</button>

a11yproject.com example (The A11Y Project):

<label for="search">Search</label>
<input type="search" id="search" name="search">
<button type="submit">Submit</button>

Both repositories provide valuable resources for web accessibility. aria-practices focuses on in-depth ARIA implementation guidelines, while a11yproject.com offers a more comprehensive and beginner-friendly approach to accessibility. The code examples reflect this difference, with aria-practices demonstrating complex ARIA usage and a11yproject.com showcasing basic accessible HTML structures.

w3c logo

wcag

1,292

Web Content Accessibility Guidelines

Pros of WCAG

  • Comprehensive guidelines covering a wide range of web accessibility issues
  • Internationally recognized standard with legal implications in many countries
  • Regularly updated to address evolving technologies and user needs

Cons of WCAG

  • Can be complex and difficult to interpret for non-experts
  • Focuses on guidelines rather than specific implementation techniques
  • May not cover all emerging technologies or user interface patterns

Code Comparison

While WCAG doesn't provide specific code examples, ARIA Practices offers practical implementations. For instance:

ARIA Practices (Button example):

<button aria-pressed="false" onclick="toggleButton(event)">
  <svg aria-hidden="true" width="20" height="20"><use xlink:href="#icon-heart"></use></svg>
  <span>Like</span>
</button>

WCAG focuses on success criteria rather than code, such as:

Success Criterion 4.1.2 Name, Role, Value
For all user interface components, the name and role can be programmatically determined; 
states, properties, and values that can be set by the user can be programmatically set; 
and notification of changes to these items is available to user agents, including assistive technologies.

Both repositories complement each other, with WCAG providing overarching guidelines and ARIA Practices offering specific implementation techniques for accessible web components.

Convert Figma logo designs to code with AI

Visual Copilot

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

WAI-ARIA: Authoring Practices Guide

This repository maintains the WAI-ARIA Authoring Practices Guide (APG).

Please do not provide commit access to this repository without coordination.

How the work is organized

  • Work is planned and prioritized in our milestones. Each milestone corresponds to a working draft or release published to w3.org.
  • Work is organized by topic in our projects. Each project corresponds to a type of design pattern or section of guidance.
  • The scope of work and roadmap are described in the project wiki.

Contributing

  1. Comment in an existing issue or raise a new issue, expressing your willingness to help and briefly summarizing the nature of your proposed resolution.
  2. An editor will confirm there are no conflicting plans and, if needed, provide guidance.
  3. Be sure you have linters installed and configured as described below.
  4. Read our wiki page about submitting pull requests.
  5. Do some fabulous work and submit a pull request.

Note: Please feel free to ask questions either through an issue or on the Authoring Practices Task Force mailing list.

Code conformance

This repository utilizes linting tools to do static code analysis and ensure consistent code quality across HTML, CSS, and JavaScript. Each linting tool and respective code standards are documented below and in the code guide.

Pull requests that contain linting errors will not be merged until the errors are resolved. To make this easier, you can install and run the tools locally before pushing code. Also note that the tools for CSS and JavaScript will automatically fix many issues if you have them installed locally. To install these tools:

  1. Make sure that you have Node.js installed, which comes with node package manager (npm)
  2. Open the directory that contains your aria-practices repository in a terminal
  3. Run npm install

The HTML validator also requires the installation of a JDK in order to run. If you don't already have a JDK installed, download the latest JDK from Oracle.

It is also highly recommended that you use a code editor that supports these tools and EditorConfig.

HTML

HTML is validated against the NU HTML Validator. Should a warning or error occur because a future ARIA feature is not yet implemented, it will be added to the .vnurc file, allowing the error to pass through.

Run locally:

npm run lint:html

CSS

CSS is validated by stylelint using the stylelint-config-standard ruleset.

NOTE: on commit, stylelint will be run on staged CSS files. If errors are found that can be automatically fixed with the --fix flag, they will be fixed and the changes committed.

Run locally:

npm run lint:css

JavaScript

JavaScript is validated by ESLint, using our own config.

NOTE: on commit, eslint will be run on staged CSS files. If errors are found that can be automatically fixed with the --fix flag, they will be fixed and the changes committed.

Run locally:

npm run lint:js

Test and fix your code

  1. Open a terminal window to the directory that contains the aria-practices repository
  2. The repository has a script defined that will test all JavaScript in the examples directory. To run it, execute the command npm test. Note: this may take a few minutes to run and will open several browser windows during the test that will gain focus.
  3. Many errors can be fixed automatically with the command npm run fix.
  4. After running fix, test again to see what you need to fix manually.

When the linter encounters errors, it will report them in the console. The error report will contain the file name and line number, and it will indicate the character or place in the line that raised the style violation. To fix an error, satisfy the change that the violation indicates.

For example, here is an error for an invalid variable name style. Variables must follow a camelCase convention.

/Users/user1/Documents/github/aria-practices/examples/slider/js/text-slider.js
  19:8  error  Identifier 'value_nodes' is not in camel case  camelcase

The error occurred in examples/slider/js/text-slider.js, on line 19 and the offending character is indicated by the number 8 after the colon. Change the variable value_nodes to valueNodes in your source file to eliminate this error.

To see the complete list of style rules that are applied by ESLint, review the .eslintrc.json file in the root of the project.

Editorial documentation

See the APG Editorial Style Guidelines for information about writing prose for the APG. The ReadMe for the ARIA specification contains additional useful editorial guidance.