refactor: fix linting and typechecking errors

src/content/blog/accessibility.mdx

@@ -5,9 +5,10 @@ import Link from "next/link";
 export const metadata = {
   title: "Accessibility Features",
   publishedAt: "2024-11-01",
-  summary: "A deep dive into the process of building an inclusive web experience, from semantic HTML to custom accessible components.",
+  summary:
+    "A deep dive into the process of building an inclusive web experience, from semantic HTML to custom accessible components.",
   tags: ["Accessibility", "WCAG", "Inclusive Design", "Web Standards"],
-  image: "/images/accessibility.png"
+  image: "/images/accessibility.png",
 };
 
 # Building an Inclusive Web Experience
@@ -21,22 +22,27 @@ For me, the motivation was twofold. Professionally, I wanted to demonstrate that
 ## The Implementation Process
 
 ### Starting with the Basics
+
 The journey began with the fundamentals: **Semantic HTML**. I ensured that the site uses a logical heading hierarchy (`h1` through `h6`) so that screen reader users can easily navigate the document structure. I also made sure to use appropriate semantic elements like `<article>`, `<nav>`, and `<main>` instead of just wrapping everything in `div`s.
 
 ### Visual Accessibility
+
 Color and contrast were next on my list. I carefully selected a color palette that meets **WCAG AA standards** for contrast, ensuring that text is readable for users with visual impairments. I also implemented a system-aware dark mode, which isn't just a cool feature—it's essential for users with light sensitivity.
 
 I also built a strict **Image Alt System**. Every image on the site is required to have descriptive alt text. This ensures that users who rely on screen readers don't miss out on the context that images provide.
 
 ### Interactive Elements
+
 One of the biggest challenges was ensuring **Keyboard Navigation**. I tested every interactive element—buttons, links, form inputs—to make sure they could be reached and operated using only a keyboard. This involved managing focus states and ensuring that the tab order was logical.
 
 ## Overcoming Technical Challenges
 
 ### The Hydration Problem
+
 Working with Next.js presented a unique challenge: **Hydration**. The split between server-side rendering (SSR) and client-side interactivity can sometimes cause issues with accessibility tools if the HTML structure changes during hydration. To solve this, I created client-side wrapper components for complex interactive features. This allowed me to keep the performance benefits of SSR while ensuring a stable, accessible experience on the client.
 
 ### Video Accessibility
+
 I didn't want to just embed a standard video player. I built a custom **AccessibleVideo** component that includes closed captions with a toggle, a full transcript, and keyboard-accessible controls. This ensures that my video content is accessible to users who are deaf or hard of hearing, as well as those who prefer reading over watching.
 
 ## Ongoing Commitment