Accessibility Checking

Accessibility requirements are unusually well suited to encoding because so many of them were written as explicit numbers in the first place. Standards for barrier-free and universal design tend to state dimensions directly: a minimum clear width for an accessible route, a minimum clear opening for a door, a minimum diameter for a wheelchair turning space, a maximum gradient for a ramp expressed as one-in-n, a minimum landing length at the top and bottom of a ramp, a required manoeuvring space in front of fixtures, a minimum number of accessible parking bays and toilets scaled to the building's size. These are clear, quantitative and testable - the exact profile of a rule that automates well. There is little of the vagueness that defeats coding elsewhere: 'the clear width shall be at least 900 mm' leaves nothing to interpret about what to measure or what threshold to apply.

Because the rules are numeric, the check is a direct comparison. Point a checking engine at a structured model in which a door carries its clear opening, a corridor its width, a ramp its slope and rise, and a toilet its internal clear dimensions, and the engine can find every relevant element, read the value, compare it to the encoded limit, and produce a pass, a fail, or a could-not-determine for each. It can also do counting rules well - are there enough accessible bays for this many total spaces, enough accessible sanitary facilities for this occupancy - which are tedious and error-prone by hand but trivial to run. And it can trace a continuous accessible route as a connectivity problem: is there an unbroken, step-free path with adequate width from the accessible entrance to each required space? That kind of path-finding is a natural fit for a model that knows how spaces connect.

The payoff is real and specific. Accessibility failures are among the most common and most consequential compliance problems caught late - a doorway a few millimetres too narrow, a ramp a fraction too steep, a turning space encroached by a later design change. Caught at submission or on site they are expensive and sometimes impossible to fix; caught by an early automated check while the plan is still fluid they are a quick correction. For a designer, running accessibility checks continuously through design is one of the clearest wins automated compliance offers - fast, consistent feedback on a body of rules that is genuinely mechanical, freeing attention for the parts that are not.

To see why the fit is strong, follow the check mechanically. An accessibility rule becomes machine-readable as a small piece of logic bound to a class of element and a property: 'for every door on an accessible route, the clear opening width shall be at least W; if less, flag'. To run it, the engine needs three things to line up. First, the model must classify elements correctly - a door must be tagged as a door, and ideally the route it serves must be identifiable as an accessible route, so the rule knows where to apply. Second, the relevant property must be present and meaningful - the door must actually carry a clear opening width, not just a nominal leaf size, because the clear opening (allowing for the frame and the open leaf) is what the rule means. Third, the threshold must be encoded correctly from the governing standard. Get all three right and the check is reliable; get any one wrong and it is not.

Some accessibility checks are simple attribute comparisons - width, slope, count. Others are spatial and need geometry, not just attributes. A wheelchair turning space is a question of whether a clear circle of a given diameter fits within the room, unobstructed by fixtures and door swings - which the engine must compute from the actual geometry, not read from a single number. An accessible toilet clearance is similar: does the required clear rectangle fit beside the WC, clear of the basin and the inward door swing? These spatial checks are more powerful and more fragile - they depend on the model carrying fixtures, door swings and obstructions faithfully, and on the checker computing clearances the way the standard defines them.

This is why the honest output of an accessibility checker has three states, not two. 'Pass' and 'fail' are the confident cases. But a great deal falls into 'could not determine' - the model did not say whether this route is the accessible route, the door had no clear-width property, the fixtures were not modelled so the clearance could not be computed. A mature checker surfaces these gaps loudly rather than silently passing them, because a silent gap is exactly how automation bias creeps in: a route with no data looks the same as a compliant route unless the tool insists on telling you it could not check. Reading the could-not-determine list is as important as reading the fails - it is the map of what the automated check did not actually cover, and what a human still must.

Here is the discipline the strong fit demands: a checker verifies the geometry of accessibility, not accessibility itself. The two are not the same, and confusing them is dangerous. A building can pass every dimensional rule - every door wide enough, every ramp within slope, every clearance met - and still fail disabled people badly. The accessible entrance might be an unmarked side door reached across a car park while everyone else uses a grand front stair, technically compliant and practically demeaning. The accessible route might zig-zag through back corridors when a short step-free path was possible. The wayfinding might be invisible to someone with low vision; the contrast between floor and wall might be too low to read the edge; the tactile and audible cues a blind user needs might be absent though no dimensional rule was broken. None of that shows up as a width or a slope, so none of it is what a geometry checker measures.

This is where universal design - designing for the full range of human ability as a matter of quality, not minimum compliance - lives, and it is inherently a judgement. Whether a route is dignified, whether an interface is legible, whether the experience is genuinely inclusive: these are assessed by people, ideally including disabled users, not computed from a model. Many accessibility standards themselves contain judgement-laden language alongside the numbers - 'suitable', 'accessible and convenient', 'where practicable' - precisely because their authors knew dimensions alone do not guarantee usability. Those clauses cannot be coded without stripping out the judgement that is their point.

So the competent stance mirrors the whole course. Use automated checking for what it is genuinely good at - catching the many dimensional and count failures early, consistently and cheaply, and freeing the designer from tedious manual measurement. Then treat a full geometric pass as the floor, not the ceiling: the necessary minimums are met, and now the real work of making the building usable begins. And never mistake the pass for an approval. An automated accessibility check is not a legal determination that the design meets the accessibility law, and never a sign-off; the encoded thresholds may be wrong or out of date, the model data may be incomplete, the usability questions are untouched, and the accountable professional, the accessibility standard and the approving authority - not the software - decide whether the building actually complies and actually works for the people it must serve.

In the Indian context accessibility checking has both a real basis and real gaps. The basis: accessibility requirements are set out in the National Building Code of India (notably its provisions on requirements for the differently abled), in the Harmonised Guidelines and Standards for Universal Accessibility, and in the accessibility obligations that flow from the rights of persons with disabilities framework - and much of what these specify is quantitative: clear widths, ramp gradients, accessible-toilet dimensions, lift and signage provisions, minimum counts. That numeric core is exactly the checkable kind, so as building submissions become more structured, accessibility is one of the domains where automated checking can add value quickly. The gap: many Indian submissions are still 2D drawings rather than richly structured BIM models, so the data a spatial accessibility check needs - fixtures, door swings, tagged accessible routes - is often simply not there to check, and enforcement of accessibility in practice remains uneven.

That combination - clear numeric rules but thin model data and patchy enforcement - is a reminder of the two boundaries. Garbage in, garbage out: an accessibility check is only as good as the model, and a 2D plan with no clear-opening data cannot be meaningfully checked no matter how good the rules engine is. And a check is never a sign-off: even a rich model that passes every dimension has been tested only against the encoded subset, on the data given, and the authority - not the tool - grants approval.

So use accessibility checking as a powerful early-warning assistant and self-check, especially valuable because accessibility errors are common and costly to fix late. But hold the line firmly. The binding accessibility requirements are the actual code and standards - the National Building Code, the Harmonised Guidelines, the relevant accessibility law and any local byelaw - never their encoded version, which may lag or misread them. Whether a design genuinely complies, how an ambiguous accessibility clause should be interpreted, and legal responsibility for accessibility all stay with the qualified professional of record, the approving authority and the governing law. And the deeper test - whether the building is truly usable and welcoming for disabled people - stays with human judgement and, wherever possible, with disabled users themselves. Automate the widths and the counts; keep the humanity of accessibility human.