What a component review covers

A component file is a program, not a page. AccessLint parses it for real and audits the markup the file itself pins down, so a finding on a .jsx or .tsx file is a defect at runtime whatever the props turn out to be. Where the source leaves something open, the review says nothing rather than guessing.

What gets reviewed

Intrinsic elements: <img>, <button>, <ul>, <table>, and the rest, with className read as class and htmlFor as for.
Literal values: alt="", alt={undefined}, tabIndex={-1}, style={{ display: "none" }}. A literal in braces is as good as a literal in quotes, including the ones that mean “no attribute at all”.
Elements inside expressions: a <div> returned from items.map(...) into a <ul> is a real defect, and gets reported on its own line.
Components you compose: <Card><img src="/hero.png" /></Card> still reviews the image. The <Card> itself is left alone.
Root layouts: a file containing a literal <html> tag is asked whether it sets lang.

What it stays quiet about

What a component renders. <MenuItem /> could render anything, so a rule that depends on what a container holds goes quiet for that container.
Values it cannot see. alt={label} is an alt attribute with an unknown value, so “missing alt” does not apply and neither does anything that judges the text.
Spread props. <img {...props} /> may carry an alt, so absence is unprovable. An attribute written after the spread is provable, because nothing can override it.
Anything that needs the rendered page. Color contrast, focus order, spacing, and whether an element is visible all depend on CSS and layout, which a source file does not carry.
Files that are not pages. Image generators built on satori or @vercel/og, and test files and fixtures, are skipped.

To check what a component looks like once it is rendered, point the free scanner at the page, or set up Flows to watch it on every deploy. Static review and monitoring answer different questions, and the second one is where runtime lives.