University of Manitoba Accessibility Audit & Audit-Matrix Pipeline Optimization
Produced At: Level Playing Field
Timeline: 2023 - 2024
The University of Manitoba engaged Level Playing Field to conduct a built-environment accessibility audit across all three campuses (~90 buildings in total) producing observations, recommendations, and Class D architectural schedules per building.
Auditing meant measuring every relevant inaccessible feature in a space: doors, hallways, color contrast, signage, wayfinding, etc.
Take a single door, for example.
There are 21 total elements we can measure.
- Clear opening width (mm)
- Hardware type (knobs — non-compliant — vs. levers)
- Hardware height (mm)
- Lock height (mm)
- View panel height at bottom sill (mm)
- Push force (N)
- Pull force (N)
- Accessible Door Opener (ADO) height (mm)
- ADO distance to door (mm)
- Signage location, height, and color contrast
- Braille/tactile signage
- ...and more
Now multiply that across ~90 buildings, each with multiple floors and hundreds of spaces. A single building alone could yield 200 to 1,600 measurable data points; averaging roughly 900 lines of data per building, or up to 81,000 lines of data across the full campus.
Manual Assessment of Element (At-Scale)
Once collected, every element had to be manually checked against 3 separate accessibility standards (MBC 2011, CSA, and WPG-ADS) each with its own criteria. That meant cross-referencing three code books, assessing compliance three times over, and writing up comments for every non-compliant item.
With varying criteria across the three codes, the ~81,000 lines of raw data scales into roughly 567,000 individual manual assessments. At that scale, a single building took an average of 32–40 hours to complete.
Auditing Language for elements were not standardized
For example, a door’s “Clear Opening Width” could be written as “clr opening w.” or “clear opening W” or “clear opening width”. This makes it incredibly difficult to sort and filter for similar elements.
Standardize the Audit-Matrix Process
To standardize the audit-matrix pipeline, 3 core solutions were developed.
- [A] Standardize language used during auditing
-
[B] Enforce said standardization that is user-friendly; and
- [C] Develop a centralized database for cross-referencing
Note: Certain areas are blurred for confidentiality.
Standardize auditing language
Each measurable element has a standardized and unique primary-key. This is crucial for automating cross-referencing building code comments and measurements with the Master Accessibility Code Database (Solution C).
Enforce standardized language by providing a PDF with set-fields
Rather than having users manually type standardized language, we opted for a standardized PDF with input fields. This prevents user-error, provides a clean .csv schema on export, and reduces manual typing required. Navigation and filter buttons are provided to easily navigate between spaces.
Centralized database, scalable to any jurisdiction
Since the standardized language for each element are unique, a centralized database can easily cross reference said primary keys automatically to ...
-
Pull code comments for all 3 standards (WPG-ADS, MBC2011, CSA);
-
Assess whether the measurements fails (0), meets standards (1), or exeeds standards (2) with threshold ranges;
- Pull general comments to use when element does not meet standards.
Of all elements are now automatcally assessed.
60–75% Efficiency Gain
Across ~90 campus facilities.The process cut the matrix processing time from ~32–40 hours to ~8–16 hours per building.
The Auditing-Matrix pipeline was designed to be scalable for LPF’s use on future projects that requires adapting to local accessibility codes in other provinces and/or countries; a tool which did not exist prior to this development.
Top