lighthouse-ci
pa11y
lighthouse-ci | pa11y | |
---|---|---|
18 | 21 | |
6,272 | 3,958 | |
0.8% | 0.7% | |
7.1 | 5.8 | |
8 days ago | 15 days ago | |
JavaScript | JavaScript | |
Apache License 2.0 | GNU Lesser General Public License v3.0 only |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
lighthouse-ci
-
help needed with lighthouse ci for angular, github actions, PROTOCOL_TIMEOUT: (Method: Debugger.disable)
- referred to https://github.com/GoogleChrome/lighthouse/issues/6512 but didnt see network.disable error - added staticdistdir as per https://github.com/GoogleChrome/lighthouse-ci/blob/main/docs/configuration.md,
-
Continuous performance audits in Nuxt with Lighthouse CI and Github Actions
This approach would suit most of the cases however to achieve more accurate performance audits you should be conducting Lighthouse tests on a dedicated server to avoid results being affected by the machine capabilities. In other words, if you are running Lighthouse audits on a repository where there are several pull requests/workflows/pushes going on, the result of this audit may not be accurate and this is what we want to avoid. For that you would need a separate machine with Lighthouse Server installed on it. So on a pull request you would trigger this machine to conduct a performance audit and return response to your repository.
-
Measuring Page Speed with Lighthouse
And finally, Lighthouse has a CI version you can run in your continuous integration. We’ll use this method to schedule periodical benchmarks.
-
Ensure your Next.js app's performance is top-notch with Lighthouse CI and GitHub Actions
TLDR; I use the Google Chrome Lighthouse CI with a .lighthouserc json configuration to test next start. The Lighthouse CI GitHub app is used to return a pass or fail status check in a PR.
-
Everything you need to know about Web Performance (in 5 Minutes)
You should also incorporate performance checks into your CI/CD pipeline. Use Lighthouse CI to run a synthetic Lighthouse test on each PR (PS: Learn why you shouldn't believe the Lighthouse score alone) and bundlesize package to raise alerts if your bundle size exceeds a certain threshold. For more nuanced data you should use WebPageTest.
-
Accessibility Automation tool for CI pipeline
You can also run Google’s Lighthouse CI tool against multiple URLs, and then hook that up to their self-hosted dashboard service: https://github.com/GoogleChrome/lighthouse-ci
-
Understanding SEO and Web Vitals for your NextJS site and how to improve them?
You can also set up lighthouse-ci as a github action to evaluate the web vitals on push or in pull requests.
-
You’re probably using Lighthouse wrong: How we got tricked by a single magic number
You can have more consistent results if you set up Lighthouse CI in an external environment to test your page or use tools like SpeedCurve, but if you need to quickly inspect a website, I suggest taking a look at Page Speed Insights.
-
Frontend Testing: No more Unit/Integration/E2E categorizations and priorities
This name is already self-explanatory, and developers just need to run Lighthouse or its CI.
-
I built an open-source tool that scans your entire website with Google Lighthouse (unlighthouse.dev)
They also have a powerful CI tool (https://github.com/GoogleChrome/lighthouse-ci) with custom timelines, may look to implement it at some point
pa11y
-
🤯 150 Articles to Satisfy Your Curiosity
Pa11y is your automated accessibility testing pal (https://pa11y.org/) by Rowan Manning
-
Scrollbars Are Becoming a Problem
And educate himself just a tiny little bit? ;)
Then in his next web project, he just might use https://github.com/pa11y/pa11y and make the world a better place!
-
Building Accessible Web Experiences: A Checklist for Frontend Developers
Pages should have descriptive titles. Make use of tag. Not just for accessibility reasons, its one of the key tools to improve your SEO.
- iFrames should have descriptive titles. iFrame is basically a page within a page, same rule applies for it too.
tag should have
lang
attribute. It helps screen readers to use correct pronunciation. If parts of your website use different languages, addlang
attribute to respective elements as well.- Roles: ARIA roles define the type of element and its purpose. Roles can be used to indicate whether an element is a button, link, menu, dialog, or other interactive components. For example,
role="button"
can be added to aelement to convey that it functions as a button.
- Labels. Interactive elements should have accessible name inside
aria-label
- Element semantics should not be inappropriately suppressed with aria-hidden. Avoid hiding elements from accessibility tree; If required, use CSS styles to make element invisible by changing opacity or visibility.
- Images should have alt attribute. Have you ever been stuck with slow connection and faced a white square wonder what's that supposed to be? Add an
alt
attribute so the images could be easily identified by text readers.Useful tools
Going through all those checkpoints might be overwhelming, and indeed, the larger your webpage or application is, the more effort it will take to find and address them.
There are, luckily excellent tools that can jumpstart the process.
- WAVE: A free online tool that provides visual feedback about the accessibility of your web content, highlighting potential issues and offering suggestions for improvement.
- axe DevTools: An accessibility testing extension for Google Chrome and Firefox that can be used directly within the browser's developer tools.
- Pa11y: An open-source automated accessibility testing tool that you can run from the command line or integrate into your CI/CD pipeline.
- Lighthouse Accessibility Audit: Excellent for a quick accessibility insight, Lighthouse is available with Google Chrome dev tools and checks highlight opportunities to improve the accessibility of your web app.
Remember that automated tools are valuable for identifying many common accessibility issues, but manual testing is often necessary to fully understand and address the user experience for people with disabilities. A combination of automated and manual testing, along with a commitment to ongoing accessibility, is key to maintaining an accessible web presence.
Happy coding!
Original post
-
Creating an Accessible Web for Everyone with Anuradha on Girl Code Coffee Chat #9
Pa11y
- Como adicionar recursos de acessibilidade em um site?
- Code optimisation for accessibility
-
Automated Accessibility Part 3: Regression Tests
Automated libraries such as axe-core and pA11y have been a very seamless way to bring accessibility testing into development teams UI testing. It can get development teams to begin to learn and grow accessibility in their teams. However, one big problem has appeared since the rise in popularity of these libraries.
- Como vocês geram métricas de acessibilidade?
-
A Practical Approach to Automated Accessibility
PA11y - It runs accessibility tests on your pages via the command line or Node.js, so you can automate your testing process
-
About a11y in general
https://github.com/pa11y/pa11y - Tool for testing ally using node.js (it also has integration with Cypress).
What are some alternatives?
WebdriverIO - Next-gen browser and mobile automation test framework for Node.js
axe-core - Accessibility engine for automated Web UI testing
lighthouse - Automated auditing, performance metrics, and best practices for the web.
cypress-audit - ⚡ Run Lighthouse and Pa11y audits directly in your E2E test suites
nightwatch - Integrated end-to-end testing framework written in Node.js and using W3C Webdriver API. Developed at @browserstack
pa11y-ci - Pa11y CI is a CI-centric accessibility test runner, built using Pa11y
WebPageTest.api-nodejs - WebPageTest API wrapper for NodeJS
Playwright - Playwright is a framework for Web Testing and Automation. It allows testing Chromium, Firefox and WebKit with a single API.
cypress-fail-fast - A Cypress plugin to skip tests on first failure.
nextjs-notion-starter-kit - Deploy your own Notion-powered website in minutes with Next.js and Vercel.
svelte-navigator - Simple, accessible routing for Svelte