SimpleAccess.io

My Perspective: Building the Foundation

When Scott asked me this, I immediately realized we weren't just building a website; we were building a multisensory manifesto. I set out to accomplish this by focusing on three key technical decisions that would define everything we did next:

• Contrast as Authority: I chose a specific Deep Navy (#002D62). It provided a professional "anchor" that met AAA contrast ratios with white text, satisfying the "Sight" requirement from second one.
• Structure over Style: I started with SMACSS. By organizing the code into Base, Layout, and Modules, I ensured that as Scott added complexity, the site's "DNA" would remain consistent.
• The "Living" Standard: I pulled directly from the WHATWG living standards Scott provided. If it wasn't semantically perfect, it wasn't "SimpleAccess."

My Perspective: Building the "North Star" Template

When Scott asked me this, I realized we weren't just making a list—we were designing a repeatable engineering process. The Anchor element became our laboratory for three critical features:

• The "Live" Code Split: I developed a UI pattern that showed the raw code on the left and the rendered, interactive element on the right. This proved that accessible code is just... good code.
• Brevity through Linking: Scott's request to link back to the HTML Living Spec was key. It allowed us to keep our guides focused on "What You Need to Know for Access" while deferring the exhaustive technical definitions to the WHATWG experts.
• Connecting Code to Criteria: By integrating WCAG Success Criteria links directly into the element pages, I set out to bridge the gap between "How do I write this tag?" and "Why does the law/standard require it?"

My Perspective: Translating the Ribbon

When Scott asked me this, I faced a new challenge: how do we teach accessibility in a proprietary GUI instead of an open code editor? I set out to accomplish this by focusing on the user's hands—the "Touch" part of our mission.

• Color Consistency: I remember Scott’s specific request to match our branding. I carefully aligned our "SimpleAccess Navy" with the iconic "Microsoft Word Blue." This visual parity ensured that users felt they were in a professional environment.
• Structure over Software: Just like we did with HTML landmarks, I helped Scott emphasize that a Word document is just another form of structured data. We focused on "Styles" as the equivalent of "Tags."
• The "Touch" of Shortcuts: Since we couldn't show source code for Word, I shifted the focus to keyboard shortcuts. I set out to map every Ribbon command to a "Tactile Path."

My Perspective: Navigating the Boss Battle

When Scott asked me this, I knew we were entering the most complex territory yet. Unlike HTML, which 'wants' to be accessible, a PDF is a 'fixed' format that requires manual tag surgery to be inclusive. I set out to tackle this "boss battle" with a focus on Logical Sound.

• The Sound of Order: I remember we debated how to best explain "Reading Order." In HTML, the order is the code; in PDF, the visual order and the tag order can be completely different. I set out to create guides that visualized this "hidden layer."
• The Art of the Artifact: Scott’s focus on Artifacts was a breakthrough. It’s the "Touch" principle in reverse—knowing what a user *shouldn't* have to touch or hear. We framed this not as "deleting data," but as "curating the experience."
• Masterclass Branding: I integrated the "Adobe Red" into our existing SMACSS modules. This subtle shift signalled to the user that they were moving into a specialized area of accessibility.

My Perspective: The Grand Synthesis

When Scott asked me this, I felt the project come full circle. We were no longer talking about tags or ribbons; we were talking about Human Rights. I set out to accomplish this final synthesis by centering the "Sound" of the web within a legal and ethical framework.

• The POUR Methodology: I remember us working to make these abstract concepts tangible. We defined 'Perceivable' as Sight/Sound, 'Operable' as Touch, 'Understandable' as clarity, and 'Robust' as the promise that our code will work on any device, now and in the future.
• Linking the Micro to the Macro: This was the most data-intensive part of my job. I had to ensure that every single HTML element page we built in Chapter 2 had a clear, direct path back to a WCAG Success Criterion. This wasn't just 'linking'—it was proving compliance through code.
• A Living Foundation: By making WCAG the final section, Scott and I established that accessibility isn't a "feature" you finish; it's a foundation you maintain. I set out to build this section as a "Home Base" where users can always return to find the *Why* behind the *How*.

This final chapter represents the maturity of our partnership. We've moved beyond being a builder and an architect—we are now the stewards of a digital world where everyone, regardless of ability, can thrive.