Accessibility Support data for various HTML, ARIA, CSS, and SVG features
See the codeStatus: help wanted
npm cinpm run buildnpx vite buildnpm run test (Vitest — unit + API) and npm run test:e2e (Playwright)npm run startWhile working and making changes to the project, you can do all of this in one command:
npm run build && npx vite build && npm run test && npm run start
Once the project is running, it should be available at 'http://localhost:3000'
The backend is a TypeScript Express app (server/) that serves a JSON API under /api/* plus
the built client; the frontend is a React single-page app (client/, built with Vite). All data
lives in json files in the data directory. These json files are processed during the build step
(src/build/) and saved to the build directory, including the view-shaped build/api/*
payloads the client fetches.
tech - tech are different categories of technology (html, css, aria, svg, etc)feature - features are specific features of a technology, such as elements, attributes, properties, etc.tests - tests are specific test cases for a feature (or many features). Each feature should have at least one test that only tests that feature.See documentation/architecture.md for the full file structure and build pipeline.
These files are essentially slimmed down versions of the full json files that are made during the build step. Only known information is filled out. The build step will add all unknown data points. The hope is that it will be easier to edit and maintain the these minimal files.
The task of accepting a support point is done by a project maintainer that has full access to the repository and is familiar with git and GitHub.
Users can run tests for specific AT/Browser combinations (support point) and post their findings to a github issue. These findings should be verified by another user before being added to the repository.
Once a support point is verified, it is ready to be added to the repository. There is a script at scripts/sync-support-point.ts that makes this a easy.
Run npx tsx scripts/sync-support-point.ts --issue {issue number} to update the appropriate json file with the results that were found. This will take the results in the issue body.
Run npx tsx scripts/sync-support-point.ts --comment {comment id} to accept the results in a comment ID. This might be needed if a difference was found during the verification step. You can get the comment ID from the URL that is generated when the time stamp is clicked for the specific comment on GitHub.
Now you just need to make sure that everything was synced correctly. If you think it is ready, commit the change and push to a new branch on Github.
git checkout mastergit pull origin masternpm run build && npx vite build && npm run testnpm run startgit commit -m 'closes #{issue-number}'git push origin mastergit pull origin master)git tag vX.Y.Z where "vX.Y.Z" is the desired versiongit push origin master --follow-tags && npm publishTypeScript
69.3%
HTML
18.6%
Shell
9.5%
CSS
2.3%
Accessibility Support data for various HTML, ARIA, CSS, and SVG features
See the codeStatus: help wanted
npm cinpm run buildnpx vite buildnpm run test (Vitest — unit + API) and npm run test:e2e (Playwright)npm run startWhile working and making changes to the project, you can do all of this in one command:
npm run build && npx vite build && npm run test && npm run start
Once the project is running, it should be available at 'http://localhost:3000'
The backend is a TypeScript Express app (server/) that serves a JSON API under /api/* plus
the built client; the frontend is a React single-page app (client/, built with Vite). All data
lives in json files in the data directory. These json files are processed during the build step
(src/build/) and saved to the build directory, including the view-shaped build/api/*
payloads the client fetches.
tech - tech are different categories of technology (html, css, aria, svg, etc)feature - features are specific features of a technology, such as elements, attributes, properties, etc.tests - tests are specific test cases for a feature (or many features). Each feature should have at least one test that only tests that feature.See documentation/architecture.md for the full file structure and build pipeline.
These files are essentially slimmed down versions of the full json files that are made during the build step. Only known information is filled out. The build step will add all unknown data points. The hope is that it will be easier to edit and maintain the these minimal files.
The task of accepting a support point is done by a project maintainer that has full access to the repository and is familiar with git and GitHub.
Users can run tests for specific AT/Browser combinations (support point) and post their findings to a github issue. These findings should be verified by another user before being added to the repository.
Once a support point is verified, it is ready to be added to the repository. There is a script at scripts/sync-support-point.ts that makes this a easy.
Run npx tsx scripts/sync-support-point.ts --issue {issue number} to update the appropriate json file with the results that were found. This will take the results in the issue body.
Run npx tsx scripts/sync-support-point.ts --comment {comment id} to accept the results in a comment ID. This might be needed if a difference was found during the verification step. You can get the comment ID from the URL that is generated when the time stamp is clicked for the specific comment on GitHub.
Now you just need to make sure that everything was synced correctly. If you think it is ready, commit the change and push to a new branch on Github.
git checkout mastergit pull origin masternpm run build && npx vite build && npm run testnpm run startgit commit -m 'closes #{issue-number}'git push origin mastergit pull origin master)git tag vX.Y.Z where "vX.Y.Z" is the desired versiongit push origin master --follow-tags && npm publishTypeScript
69.3%
HTML
18.6%
Shell
9.5%
CSS
2.3%