Unit 6: POSH as a team practice

POSH is a team sport

• Semantic HTML isn't just one person's job.
• Codebases, design systems, and products are team efforts.
• A culture shift toward semantic HTML means better accessibility, quality, and sustainability.

Consider semantics in code reviews

• Make semantics part of the review checklist:
  • Are headings used correctly?
  • Are lists and tables structured correctly?
  • Are links and buttons used correctly?
  • Does this element reflect what it is, not just what it looks like?
• Could this be a section reather than a div?

Document semantic expectations

In your design system or component library:

• Specify the underlying HTML elements.
• Include notes on roles, relationships, and expected behavior.

Help new team members understand the why, not just the how.

Learn to spot anti-patterns

Look for symptoms of non-semantic code:

• Lots of nested <div>s without clear notes.
• Missing landmarks.
• Clickable <div>s without focus styles.
• Heading out of order.
• Missing <fieldset>s and <legend>s.

The earlier you catch these, the easier they are to fix.

When to compromise

Sometimes business, branding, or framework contraints force compromises.

If you must use ARIA or div-based interactions:

• Document it clearly.
• Mimic native behavior as closely as possible - remember keyboard, roles, and states.

It's okay to make tradeoffs thoughtfully - intentional exceptions are better than accidental mistakes.

Unit 6: POSH as a team practice

Key takeaways

1. Semantic HTML is a shared responsibility, not an extra task.
2. Small improvements now prevent big accessibility headaches later.
3. Building a POSH mindset into your team creates better products for everyone.
4. Accessibility isn't a checklist, it's a craft we practice together.