Accessibility statement
I'm Alexandra Ignatova — the owner of easybridge.dev. This site is about accessibility, so it had better be accessible itself. Here's where it stands, how I check it, and what to do if something gets in your way.
Conformance
The target is WCAG 2.2, Level AA. As far as I know the site meets it today. That said, I test it myself, with my own setup — one person, two screen readers. If something slipped through, see Feedback below.
What's in place
- Everything works with a keyboard. Focus is visible, and there are skip links to the content and to the footer.
- Real headings, lists, landmarks and tables. Data tables have captions and proper row and column headers — a script checks every table on each push, so there are no exceptions.
- Text zooms to 200% and the layout holds at 320px without sideways scrolling. Wide tables and code get their own scroll region instead.
- Light and dark themes. The CSS also follows your system settings for reduced motion, reduced transparency and contrast.
- Contrast is checked in both themes: text, links, focus rings, controls.
- Images have alt text. Decorative ones are hidden from screen readers.
- Tag chips like a11y, WCAG or VPAT are wrapped in
abbrwith the full term. In posts, I write acronyms out the first time they appear. - Two things on this site change without a page load: the post count when you filter the blog, and the "copied" message on code samples. Both are announced through polite live regions. Your focus doesn't move.
- There's a print stylesheet. Black on white, no navigation, the URL printed after every external link and email address, and code blocks that don't get cut in half between pages.
How I test
Every build runs pa11y (WCAG 2 AA) on every page, validates the HTML, and runs the table check mentioned above. If any of them fail, the push doesn't go through.
Automated tools don't catch everything, so the rest is manual: keyboard walkthroughs of each template, VoiceOver with Safari on macOS, NVDA with Firefox on Windows. I redo this when a template or a shared component changes — not on every post.
Known limitations
- Some code samples are wider than a phone screen. They scroll sideways in a focusable region rather than wrap — wrapped code is wrong code.
- Links to GitHub, LinkedIn, the W3C and so on leave this site, and I can't vouch for what's on the other end. Links that open a new tab say so.
- The mobile menu uses the Popover API. Older browsers load a polyfill, and if even that fails the menu falls back to a plain list of links. Uglier, but it works.
Feedback
Found something broken? Email alex@easybridge.dev. Tell me the page, what happened, and if you can, which browser and assistive technology you were using. I usually answer within five working days, and confirmed barriers go to the top of my list.
About this statement
- Standard
- WCAG 2.2, Level AA
- Assessment approach
- Self-evaluation by the site owner
- Technologies relied upon
- HTML, CSS, JavaScript, SVG, and WAI-ARIA
- Statement published
- Last reviewed