WCAG has dozens of individual guidelines. But every single one traces back to four core principles: Perceivable, Operable, Understandable, and Robust. POUR.
Most explanations of POUR read like a textbook. We are going to show you how these principles actually show up when we build a client website from scratch in Next.js.
P is for Perceivable
Can people perceive your content through at least one of their senses?
This is where Melissa's OT background hits hardest. Her training taught her how people rely on screen readers, magnification tools, or high contrast settings just to read a webpage. When a website fails on perceivability, those users are not mildly inconvenienced. They are completely shut out.
Here is what Perceivable looks like in our actual builds:
Every image gets real alt text. Not "IMG_4823.jpg." Not "image." A description like "Owner standing in front of completed kitchen renovation with white quartz countertops." Screen readers read this aloud. It is the only way a blind visitor knows what that photo shows.
Color is never the only indicator. If a form field has an error, we do not just turn the border red. We add an error message, an icon, and an aria description that screen readers can announce. Melissa knows from her OT career that people with color vision deficiency would never see a red border.
We test contrast on every component. Tyler checks color contrast ratios during development, not after launch. Our minimum is 4.5:1 for body text, which is the Level AA requirement. We often exceed it.
Captions are not optional. If your site has video content, it needs accurate captions. Not the auto generated ones that turn "occupational therapy" into "occupational therapy" if you are lucky and "occupant thermal puppy" if you are not.
O is for Operable
Can people navigate and use your website without a mouse?
This one is personal for us. Melissa's OT career gave her direct experience with people who have limited fine motor control, tremors, or no use of their hands. They navigate the web with keyboards, switch devices, voice commands, or head tracking. If your website requires a mouse to function, you have told those people they are not welcome.
Here is how Operable shows up in our code:
Skip links on every page. When you load any Egmer built site, the first thing a keyboard user can do is hit Tab and see a "Skip to main content" link. This lets them jump past the navigation instead of tabbing through 15 menu items on every single page. Tyler builds this into the site layout component so it exists on every page automatically.
Every interactive element is keyboard accessible. Buttons, links, form fields, dropdowns, modals. If you can click it with a mouse, you can reach it with Tab and activate it with Enter or Space. We test this during development, not as an afterthought.
Focus indicators are visible. When you tab through our sites, you can see exactly which element is focused. Many sites remove focus outlines because designers think they look ugly. We keep them because Melissa knows from her OT background that someone is relying on them.
No seizure triggers. Nothing on our sites flashes more than three times per second. This is a medical safety issue, not a design preference.
U is for Understandable
Can people understand your content and predict how your site behaves?
This goes beyond readability. It is about whether your site makes sense.
Consistent navigation. The menu is in the same place on every page. The logo always links home. The phone number is always in the header. Predictability is accessibility.
Clear form labels and error messages. Every form field has a visible label. If someone submits a form with errors, we tell them exactly what went wrong and how to fix it. "Please enter a valid email address" is useful. A red border with no explanation is not.
Plain language. We write content for real people, not search engines and not compliance auditors. If a heading can be simpler, we make it simpler.
Proper heading hierarchy. Tyler builds every page with a single H1, followed by H2s for major sections, H3s for subsections. This is not just an SEO thing. Screen reader users navigate pages by heading level. If your headings jump from H1 to H4, it is like ripping chapters out of a book.
R is for Robust
Will your site work with current and future assistive technologies?
This is the most technical principle, and it is where Tyler's engineering approach matters most.
Semantic HTML, not div soup. Every element on our sites uses the correct HTML tag. Navigation goes in a nav element. Main content goes in main. Lists use ul and li. Articles use article. Screen readers rely on this structure to help users understand the page layout. Sites built with nothing but div tags give screen readers nothing to work with.
ARIA attributes where needed. When native HTML is not enough, we add ARIA (Accessible Rich Internet Applications) attributes that tell assistive technologies what an element does. Our custom AccessibilityToolbar uses ARIA labels, roles, and states so screen readers can announce what each control does.
Valid, standards compliant code. Every site we build uses TypeScript, which catches errors at compile time. We use React Server Components, proper HTML semantics, and follow web standards. This is not just good engineering practice. It is how you ensure your site works with screen readers that exist today and assistive technologies that have not been invented yet.
We test with actual assistive technology. Not just automated checkers. Melissa tests with screen readers and keyboard navigation because her OT training taught her how people with disabilities actually use the web.
Why This Matters More Than a Checklist
You can find a hundred WCAG checklists online. Check the boxes, move on. But that is not how accessibility actually works.
POUR is a way of thinking about the people who will use your website. Melissa does not think about "WCAG 2.1 Success Criterion 1.4.3" when she evaluates a site. She thinks about someone like Maria who uses a screen reader, or James who navigates with a head switch, or David who needs high contrast to read anything on screen. Those are the kinds of people her OT career taught her to design for.
That is the difference between building a website that passes an automated scan and building one that actually works for real people. We build the second kind.