City of Northline: concept study
Concept project. City of Northline is a fictional city. This is a Thirdhall design and engineering demonstration, not a client engagement. The “before” data comes from real public websites; the “after” is the concept, measured the same way. View the concept
Before: what sites like this look like today
We scanned Rhode Island's 39 city and town websites for WCAG 2.1 AA failures on the homepage and a key task page.
- 85%had a serious or critical accessibility failure (33 of 39)
- 13link to no accessibility statement
- 7rely on an overlay widget instead of fixing code
- 73average benchmark score of two large Rhode Island city websites
The problem we designed against
City websites are usually organized like the org chart. Residents arrive with an errand (a permit, a bill, a trash day) and have to work out which department owns it. Agendas and forms are often PDFs that screen readers struggle with, and most sites offer nothing in Spanish or Portuguese.
What the concept does
- A task-first homepage: the six most common errands, a live alert, and search, above everything else.
- A guided permit finder: three questions return the permit, fee, review time, documents, and a start button.
- Bill payment with every way to pay and a payment-plan note before the due date, not after.
- Agendas as accessible web pages, with captions and minutes linked from the same table.
- A Spanish homepage, linked with proper language markup from every page.
Before and after, same benchmark
| Area | Typical real site (avg of 2) | Concept |
|---|---|---|
| Accessibility | 82 | 100 |
| Documents | 64 | n/a |
| Mobile performance | 60 | 99 |
| Security & maintenance | 65 | 80 |
| Content health | 94 | 100 |
| Language access | 60 | 100 |
| Privacy | 90 | 100 |
| Overall | 73 (C) | 96 (A) |
What this shows, and what it doesn't
- It shows the design patterns and build quality we deliver, measured with the same tools we use on real sites.
- It does not show results with real residents, staff, or traffic. A concept has no users, no legacy content, and no integrations, which makes high scores easier. Those are where real projects get hard.
- Automated checks find a subset of accessibility problems. Real projects add manual testing with assistive technology.
How we'd measure a real engagement
- Benchmark before launch and after, on the same rubric.
- Task completion for the top errands, not page views.
- Calls and emails about questions the site should answer.
- Share of documents that are accessible, and time to publish one.