How this site works
We build this site openly, against a clear set of standards.
Our design principles
Start with what students need
Every page exists because students asked a real question, not because it looked good on an org chart. If a page does not help you do something, we cut it.
Use simple, direct language
Short sentences, everyday words, no jargon. If a rule or process is genuinely complicated, we explain it in the smallest number of plain steps we can.
Make it work for everyone
Keyboard-only, screen readers, small screens, slow connections, both languages: the site should work well under all of these, not just the easy case.
Join up our channels
This site, our socials, and the official BIR office links should tell a consistent story. Where information comes from the BIR office or the university rather than from BIRSA, we say so and link to the source.
Keep improving in the open
Content is never really 'finished'. We'd rather ship something useful now and fix gaps quickly than wait for a perfect version that never arrives.
Accessibility statement
This is a voluntary accessibility statement, modelled on the one the UK Government Digital Service asks its services to publish. BIRSA is a student-run society, not a public body, so no law requires this. We publish it because we think every site should be honest about how usable it is.
This site is partially compliant with the Web Content Accessibility Guidelines (WCAG) 2.2 level AA. It is “partially” compliant because we have not yet tested it with real assistive technology, and because of the other known issues listed below, not because of a specific failure we are aware of.
What we do
- Every feature can be operated with a keyboard alone, with a visible focus indicator.
- Pages use correct heading structure and landmark regions so screen readers can navigate them predictably.
- Our colour palette is contrast-checked, and we never use colour as the only way to convey meaning.
- Motion respects your system's "reduce motion" setting: we do not add animation that ignores it.
- Pages stay readable and usable at 320px-wide screens and at 400% browser zoom.
- The whole site is bilingual, with the correct `lang` attribute set on every page.
- The site supports both light and dark colour modes, both checked against WCAG contrast requirements. It follows your device setting by default, and you can switch it any time with the toggle in the header.
How we test
Two automated test suites run on every code change, in Chrome, Firefox and Safari's rendering engines. The first (axe-core) sweeps every page template, in both Thai and English and in both light and dark colour mode, against the WCAG 2.0, 2.1 and 2.2 A and AA rules. The second drives every page with a keyboard only, checking things the first cannot: that focus is always visible and never trapped, that menus and dialogs open and close correctly, and that a complete form can be finished without a mouse. Automated testing alone does not prove a service is accessible: it catches a defined set of technical faults and nothing more. We have not yet tested this site with real assistive technology, such as a screen reader, a screen magnifier, or speech-recognition software. That is the biggest gap in our current testing, and the reason this statement says “partially compliant” rather than “compliant”.
Known issues
These are the known issues:
No assistive-technology testing yet
Our automated checks catch a defined set of technical faults, but automated testing alone cannot show whether the site actually works well for someone using a screen reader, a screen magnifier, or speech-recognition software. We have not carried out that testing yet, with any of those technologies, so some barriers may go unnoticed (WCAG 4.1.2 and others). Planned before we leave beta; use the reporting route below if you hit a barrier before then.
Some placeholder content
A few details (example dates, room numbers and similar) are placeholder text pending review by the BIRSA committee, and are labelled as such. This is a content-accuracy gap rather than an accessibility barrier, but we mention it for honesty.
When we prepared this
This statement was first prepared on 14 July 2026 and last reviewed on 30 July 2026. We review it at least once a year, and whenever we make a significant change to the site.
Report a problem
If something on this site is hard to use, contact BIRSA and describe the problem and, if you can, the page and device you were using. You can also email us directly at birsa@tu.ac.th / birstudentassociation@gmail.com. Contact BIRSA
Performance and data
We use cookieless, privacy-friendly analytics to understand which pages are useful and where people get stuck, never to track individuals.
How this site is maintained
The content and code for this site live in a version-controlled repository. Changes are reviewed by the BIRSA committee before they go live, and we expect to iterate on this site frequently rather than treat it as a one-off project.