To "equalify" something is to fix it with an accessibility-first mindset. Accessibility-first means raising the bar of work to guarantee that people with disabilities can easily use tools and access content.
Equalify's handbook is modeled after Gitlab's handbook and contains comprehensive information about everything related to Equalify. By publishing our handbook publicly, we're fostering a culture of transparency and openness and ultimately contributing to a more accessible internet for all.
Equalify is a platform for managing website accessibility focused on improving conformance to the Web Content Accessibility Guidelines (WCAG). We offer a managed service at https://equalify.app/ and repositories in the EqualifyApp organization on GitHub for users to create their version of Equalify. Users who create their version are encouraged to contribute to our open-source codebase to work together to make the web more accessible to everyone.
We aim to equalify 100 million accessibility issues by 2028. With over 96% of the million most popular homepages failing WCAG compliance testing1, we have a lot of work in front of us!
Equalify is built around the belief that everyone should have access to internet tools and information. Our commitment to Open Source. All Equalify code is published under approved Open Source licenses. Open Source licenses ensure that our software remains free and open for everyone to use, study, and modify. By making our code publicly available, we hope to inspire others to join us in equalifying the internet.
Equalify is maintained by a team from the University of Chicago Illinois (UIC) Technology Solutions. More information can be found on the UIC IT Accessibility Engineering page.
- Issue Reported in One Repo: All issues are in the main Equalify repo at this URL: http://github.com/equalifyEverything/equalify
- One-Week Sprint Cycles: Each issue should contain work that fits into two-weeks. Equalify milestones align with each sprint cycle.
- @bbertucc is Project Manager: Tag
bbertuccwith any questions that need management.
Each feature has initial development, functionality testing, accessibility testing, and deployment scoped. The scope includes due date, overview of expectations, and budget.
Issue #422 is an example of a detailed list of functionality and accessibility tests for our version one. The date that everyone agrees on is set using milestones. We check in on the progress asynchronously and every contributor meeting.
Here is how an issue goes to production:
- Create a GitHub Issue.
- @bbertucc will assign someone to the issue.
- Assignee creates a branch for the update.
- Assignee merges any updates with staging branch.
- Assignee comments on an issue that the update is ready for testing and assigns @bbertucc to test.
- Update is reviewed by @bbertucc. He may add @kevinandrews1 or @alexstine if accessibility needs to be tested.
- When update is finalized, @bbertucc creates a PR to merge with main branch and assigns @azdak, @wilsuriel03, @alexstine or @heythisischris to review code.
- When approved, update is merged with main branch.
- @bbertucc will run final tests on production and close issue if update is finished.
*@bbertucc will rush any hotfixes outside of deployment process.
Contributor is controlled by @bbertucc. As Equalify grows, the goal is to move toward a shared, community-led decision-making process.
Yes! Many changes have happened since Equalify was launched. Good tech evolves!
Post additional questions, bugs, and enhancement requests under the main repo's "Issues" tab (linked). Your feedback makes Equalify a better organization. We also use Slack for folks building Equalify.