October 2026 Development Report

Reporting period: Sep 1 – Oct 5, 2026 Sources: #654, #655, #656, #660, #657, #658, #659, #661, #662 Contributors: B. Bertuccelli-Booth, C. Aitken, T. Daniel

Executive Summary

October was the team's most active month to date, with 29 tasks completed and 221 code commits across 7 repositories. The team closed out the FOSS deployment milestone and delivered dark mode, mobile layouts, and new site onboarding and CSV import features. It also improved how the platform handles scan failures, preserving results from the last valid scan rather than clearing blocker counts. Work on the Iris scanning engine accounted for the majority of commit volume and produced the first release of Equalify Iris for WordPress, which brings automated PDF accessibility tagging directly to WordPress sites.

Highlights

• Launched Equalify Iris for WordPress, a new plugin that tags public PDFs in place, finds them anywhere site visitors can reach, and supports large site networks. It also keeps each PDF's icon linked to its accessible version and makes that icon screen-reader friendly.
• Made scan results more resilient to failures. When an audit-level scan fails, the platform now keeps data from the last valid scan instead of clearing blocker counts, and failed scans are clearly marked on the scans chart and table.
• Added dark mode and mobile-friendly layouts to improve usability across devices and viewing preferences.
• Delivered site onboarding and CSV integration. Features include automated site crawling, onboarding built into the Build Audit workflow, support for externally linked CSV files as a source of audit URLs (enabling WordPress plugin integration), and CSV-based user import.
• Completed the FOSS deployment milestone, including infrastructure provisioning scripts, a deployment strategy, deployment documentation, and a developer-focused introductory guide.

Key Metrics

Completed Work

Team

• Completed the FOSS deployment milestone. The team evaluated and selected an Infrastructure as Code framework and wrote build scripts to provision all required components (Lambdas, database, and the relationships between them). It also set a strategy for pushing code updates to provisioned environments and produced technical deployment documentation.
• Produced developer-focused documentation that introduces how to use the platform at a high level.
• Added dark mode and mobile breakpoints to support a wider range of devices and display preferences.
• Delivered site onboarding features, including a new Lambda for automated site crawling, and integrated onboarding into the Build Audit workflow.
• Added CSV integration. Audits can now use externally linked CSV files as their source of URLs, with regular or on-scan refreshes, which enables WordPress plugin integration. Administrators can also import users from a CSV file.
• Held a presentation planning discussion.

T. Daniel

• Changed audit-level scan failure handling so the platform keeps data from the last valid scan. Previously, a failure moved active blockers into the archive, cleared blocker counts, and made individual blocker pages unreachable.
• Added visual indicators for failed audit-level scans on the scans chart and table.
• Reorganized the crowded filter area at the top of the Detailed View and renamed "Filter by Categories" to "Filter by Rules" for clarity.
• Moved the Blocker ID into its own column in the Detailed View and moved the duplicate blocker count into the description column.
• Reviewed and refined the Recommendations view.
• Added the current software version to the main Audits screen.
• Clarified the login page language to explain that pre-approval is required to access the Equalify dashboard through single sign-on, rather than implying that all SSO users can sign in.
• Moved documentation into the main repository and updated user documentation to reflect recent changes.
• Completed the work tracked in issue #656.
• Responded to the external API feature request (#655), and responded to and closed out user support tickets.
• Updated the project tracking sheet.

C. Aitken

• Completed the monthly development report.
• Completed a new "Recommendations" view which allows users to see an easily organized dashboard of highest-impact blockers and what actions they can take to effectively remediate their website(s).
• Added a new feature called "Historical Scans" which allows users to view blockers from previously run scans inside of the Detailed View.
• Added comprehensive KPI tracking for Equalify stats to the dashboard, which syncs with broader DASE stats.

Notable Events

• Sep 9: Responded to an external request for a public API. The team explained that an externally accessible API is not currently on the roadmap, largely because it would require a new, separate security layer.
• Mid-September release: Shipped a new version with improved scan timeout handling. An external user's bug report led the team to the underlying timeout issue, and on Sep 22 the team confirmed that the fix was included in the release from the previous week.
• Sep 25: Investigated a user-reported color contrast concern. The investigation found multiple instances of text on the site falling below the 4.5:1 WCAG contrast standard, which indicates the scan results were accurate. The partner noted that the user may have had difficulty matching flagged elements to the corresponding content on the page.
• Sep 25 – Oct 2: Investigated timeout errors on large scans. A user was unable to access past scan results through the chart because of the timeout error. The team identified scan size as the likely cause, and C. Aitken began a long-term fix.

Risks & Blockers

• Audit-level timeouts on large scans: Large audits can exceed current timeout limits. In one reported case, this prevented a user from viewing past scan results. C. Aitken is increasing the audit-level timeout and making sure individual URL timeouts close out properly. As of Oct 2, the fix was expected to roll out within about a week.
• Historical scan display issues: Testing of the new historical scans feature found that the return link in the banner is the same color as the banner in dark mode. Some significantly older scans, possibly from before the current archiving architecture, also display inconsistently. Both issues are tracked for follow-up.
• API access for external integrations: External users have requested programmatic access. Supporting it would require a separate security layer, and the feature remains in the backlog for discussion.
• Add historical scans to the Detailed View. A dropdown will let users select a previous scan and review its archived blockers, with a banner to distinguish historical mode. (C. Aitken)
• Create a dedicated Recommendations view alongside the Summary View and Detailed View. All duplicate blocker grouping filters and logic will move into this view, along with a brief plain-language explanation. (C. Aitken)

In Progress & Upcoming

Development

• Increase the audit-level scan timeout and make sure individual URL timeouts close out properly. (C. Aitken)
• Add a summary block that explains duplicate blockers in plain terms, and identify repeated blocker codes across URLs. (C. Aitken)
• Test the accessibility of the new duplicate blocker tooltip and consider replacing it with a modal. (C. Aitken)
• Better highlight pages with high blocker counts or ratios. (T. Daniel)
• Evaluate an optional LLM-generated summary block. (T. Daniel)
• Add a user-closable "updates" area alongside the version display. (T. Daniel)

Operations

• Polish the deployment documentation. (T. Daniel)
• Finish connecting the Hub to the main repository. (C. Aitken)
• Follow up on issue #654 once the latest staging release is deployed to production. (C. Aitken)
• Update the documentation to cover the historical scans feature.
• Publish the monthly development report.

Newly Identified Work

• Continue enhancing issue export and integrations.
• Add contextual helper text to the Build Audit screen.
• Expand blocker status options beyond "Ignore" to include additional user-settable tracking states, such as Needs Review.
• Improve scheduled email notifications, which currently serve only as fixed-schedule reminders. Planned improvements include URL and blocker counts and summary content, plus an optional notification when a scan completes.
• Add audit tagging so users can create, assign, and filter audits by tag.
• Evaluate API support for external integrations.
• Plan a promotional release for the deployable version.
• Fix the historical scans banner link color in dark mode and the display of older scans.
• Address issue #660.

Development Activity

Contributor Activity

Active Repositories

Recent Commit Highlights

• Released the first version of Equalify Iris for WordPress. The plugin tags public PDFs in place, finds them anywhere visitors can reach, runs on large site networks, and keeps each PDF's icon linked to its accessible version in a screen-reader-friendly way.
• Made the Iris PDF tagging pipeline more resilient. It can now tag documents even when the Tesseract text recognition engine is unavailable, placing words approximately, and it reports clearer diagnostics when Tesseract fails or is stopped.
• Improved the accuracy of PDF text reconstruction. Changes include correct spacing at inline boundaries and after list labels, preserving oversized first words on the page, line breaking at nested blocks, and verification of a scan's PDF/UA compliance claim.
• Added AI-assisted pull request reviews to the Iris PDF repository.
• Expanded the DASE Hub with a new Sustainers program page that includes an application form and notifications. The team also renamed Equalify Reflow to Iris with a refreshed page, updated the About page with August 2026 platform metrics, and set the Hub to pull the User Guide and Technical Docs from the main repository.
• Published the September 2026 development report, documented the session tracking KPIs, and added a recommendations screenshot to the user guide.
• Refined the AI alt text benchmark. Updates include better rendering of image-map regions under review, a smaller image archive, a fixed download button, and corrected hosting and local serving instructions.

Planned Sprints

Design & Maintenance Sprint (1-2 weeks)

This sprint will set a cohesive visual direction for the platform. Planned work includes agreeing on an overall palette, defining branding guidelines, building a component design system for interface consistency, completing code and style cleanup, and producing promotional materials. The sprint will also include roadmap discussions about roll-up reporting across multiple audits and finer-grained control over which audits each user can see.