ACCESSIBILITY STATEMENT
Designed and engineered toward WCAG 2.2 AA.
This is not a claim of full or certified compliance. It's a description of the approach, the decisions and the known gaps, so accessibility is verifiable rather than asserted.
Approach
Accessibility is treated as a design constraint from the start of a page or component, not a pass applied afterward. Concretely, that means:
- Native HTML elements are used for their built-in semantics (buttons, links, lists, headings, landmarks) instead of ARIA-augmented
divs. - Every interactive control has a visible focus state, an accessible name, and works with keyboard alone.
- No information is conveyed by color alone, and no content is available only on hover.
- Motion is decorative, not load-bearing: every animated transition has a static, immediately understandable equivalent.
- Core content - navigation, career history, writing and contact details - is present in the HTML and does not depend on JavaScript to exist.
Keyboard support
| Action | Key |
|---|---|
| Skip to main content | Tab on page load, then Enter |
| Open "Ask my career" | Ctrl/⌘ + K |
| Close a dialog | Esc |
| Move between controls | Tab / Shift+Tab |
| Activate a button or link | Enter or Space |
Motion preferences
The site respects prefers-reduced-motion automatically. It also provides a manual "Reduce motion" control in the header, independent of the operating-system setting, since preferences can vary by context. The choice is stored on your device and re-applied on your next visit.
Semantic structure
Pages use a single <h1>, a logical heading hierarchy, and landmark regions (header, nav, main, footer) so assistive technology can navigate by structure rather than by reading everything in order.
Multilingual accessibility
Every page declares its language via lang, and text in the other language (article titles, quoted material) is marked with its own lang attribute so screen readers switch pronunciation correctly. The language switcher keeps you on the equivalent page in the other locale.
Testing methodology
This site is checked through a combination of manual keyboard-only navigation, spot checks with screen readers, semantic HTML review, and automated tools such as axe and Lighthouse when available. Automated tools catch a subset of issues; manual review catches the rest. Neither substitutes for the other.
Reporting an issue
If you encounter an accessibility barrier on this site, please email gdosreis@acm.org with the page and a description of the issue. Reports are reviewed personally.