diff --git a/pages/writing/accessibility-top-100/imdb.md b/pages/writing/accessibility-top-100/imdb.md
new file mode 100644
index 00000000..c56efd90
--- /dev/null
+++ b/pages/writing/accessibility-top-100/imdb.md
@@ -0,0 +1,162 @@
+---
+title: "How accessible is IMDb? - Writing - Dustin Whisman"
+description: "How accessible is IMDb? This is part 8 of a series evaluating the accessibility of the top 100 websites in the US."
+articleTitle: "How accessible is IMDb?"
+layout: default
+date: 2024-08-25T00:00:00.000Z
+tags:
+ - writing
+ - accessibility top 100
+---
+
+# How accessible is IMDb?
+
+_This is part 8 of a [series](/writing/accessibility-top-100/) evaluating the accessibility of the top 100 websites in the US. This time I'll be taking a look at IMDb. Read the [methodology description](/writing/accessibility-top-100/methodology) to learn about my process._
+
+{% include 'partials/published-date.njk' %}
+
+## What I tested
+
+For IMDb, I tested the [home page](https://www.imdb.com/), the [search results page for “twisters”](https://www.imdb.com/find/?q=twisters&ref_=nv_sr_sm), and the [movie page for Twisters](https://www.imdb.com/title/tt12584954/?ref_=fn_al_tt_1) (no real reason, it’s just a recent movie at time of writing). In a deviation from the norm, I’m actually going to start with the movie page, then search, then the home page, since in my experience, few people go to IMDb’s home page, then search for a movie—they usually land there from some external search engine.
+
+
+
+
+
+
+ These are the pages that were tested on desktop.
+
+
+
+
+ These are the pages that were tested on mobile.
+
+
+I tested IMDb on August 25th, 2024.
+
+## Testing a movie page
+
+### Automated scans
+
+Links on IMDb don’t use underlines or anything else besides color to distinguish them from text, which is usually only acceptable in navigation or other link-heavy contexts. There are also a couple links with an SVG that visually reads as “IMDbPro” but have no accessible text alternative. An SVG `title` would work, or an `aria-label` , visually hidden text, anything really.
+
+It appears that most, if not all SVGs are given `role="presentation"`, which may cause them to still be announced by some screen readers, so `aria-hidden="true"` may be more appropriate. Whether the SVGs *should* be treated as decorative is another question, but cherry picking some examples, most of them are within links or buttons that use `aria-label` or otherwise have accessible names that would be redundant with a named icon.
+
+The “Did you know” section has some… interesting design choices that lead to issues such as nested interactive controls.
+
+
+
+ There are goofs here alright.
+
+
+This card is a `li` element with `role="presentation"` (so why even bother with list semantics?) that contains two `a` elements with `role="button"` ([don’t make me tap the sign](/writing/when-to-use-links-vs-buttons/)), and a `div` element with `role="button"` that contains an actual `button` element along with the content of the card. All of this is in service of implementing “See more” functionality to reveal one more paragraph than was already visible. I should note that these are already summaries of more detailed pages, so it would be way simpler and far less broken to just show the whole summary and add a single “See more” link, but with unique names like “See more goofs” or “See more quotes”, etc.
+
+Clicking on those link-buttons will open a new page with more info, so they certainly should not be treated as buttons, and they both have the same accessible name (“See more”) as the button that reveals the missing paragraph. Not super helpful for finding your way around.
+
+There are a lot of cases where the accessible names of interactive elements don’t begin with or match the visual text of those elements. For example, the harmburger menu, which visually reads “Menu”, has `aria-label="Open Navigation Drawer"`. This breaks speech controls, since software being told to click the menu button wouldn’t be able to find a button (or the correct button) called “menu.” The same goes for a link that visually reads “Writers” but has the accessible name of “See full cast and crew.” There are 45 total cases like this on one page.
+
+Some quick hits for other issues:
+
+- Not all `id` attributes are unique
+- Some content is not contained by landmark regions
+- Some `for` attributes don’t point to inputs with matching `id` attributes (that’s very bad)
+- Some `label` elements have `role="button"` (why?!)
+- The `html` element does not have a `lang` attribute
+- There are some `span` elements with `aria-label` attributes
+- Just a tiny bit of color contrast issues
+- Several issues flagged for the search bar (I’ll get into that later)
+- A whole lot of redundant ARIA roles for elements that have implicit roles, like `
+ 
+ 
+