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!
At Equalify, we believe everyone should have access to internet tools and information. Our commitment to access is reflected in our mission (100 million equalified accessibility issues by 2028) and our business practices, typified by this handbook. Additionally, our code will be published under 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 commercialized open source software (COSS). We sustain ourselves by selling subscriptions to our managed service, https://equalify.app. We follow a skinny to thin crust open core model, more info on that here.
Blake Bertuccelli-Booth (@bbertucc) currently has ownership of Equalify, as noted in our Legal Repo. Blake plans to retain ownership until the organization reaches sustainability.
Our funds go to bounties. We aim to pay people bounties for getting the work of Equalify done. As of now (June 12, 2024), we've budgeted $11k/mo for bounties for the first year, then doubling that number each year after. You can see our budgets in our Accounting Repo. In Year 5, or whenever we get to sustainability, we'll probably hire people in more traditional employment arrangements. (That will probably also be the time Blake hands over control to someone else, preferably someone who relies on assistive technology.)
@bbertucc will report Equalify profit and loss, including his own hours, to the #accounting channel in Equalify's Slack at the start of every new month.
Equalify has a standard rate of $70/hr. This rate was agreed on at our November 18 meeting. Every bountied issue should be estimated, approved, and invoiced accordingly at the end of the month. Note: We've also budgeted $90/hr for Unlocked Freedom Access (Kevin) to provide accessibility testing. Kevin will invoice us for services at the end of each month.
Anyone assigned an approved bounty must send an invoice for hours worked. Invoices should include the number of hours, date, and URL of where approval for hours was given. @bbertucc will pay assignee via Gusto and update issue with note on payment.
No. Equalify is an Open Source project. Any work not explicitly budgeted and approved via a bounty is considered a voluntary contribution. Volunteer contributions are required to realize a vision of an Open Source Web Accessibility platform. We consider every volunteer contribution a vote for Open Source Web Accessibility.
- Issue Reported in One Repo: All issues are in the main Equalify repo at this URL: http://github.com/equalifyEverything/equalify
- Two-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.
Yes! Equalify Inc. was founded recently (August 7, 2023). As we meet new challenges, this document will evolve.
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. You can join our Slack here: https://join.slack.com/t/equalifyapp/shared_invite/zt-1sfbgf0fa-CzIHlbFOs0Ww1iSTK4LQ2w