In one paragraph
Blink elements are deprecated and must not be used is a legacy-markup finding for visible blink elements in the supplied rule. Modern major browsers do not normally animate the element, so its presence alone does not prove an actual flashing hazard or WCAG failure. Replace obsolete markup while preserving the message, then inspect any real animation, pausing, and flashing behaviour separately.
Why it matters
Unexpected blinking can interrupt reading and attention, particularly when it cannot be stopped. WCAG 2.2.2 requires suitable control for automatically starting moving, blinking, or scrolling information that lasts more than five seconds alongside other content, unless essential to the activity.
That criterion is about actual behaviour and its conditions, not merely an author's historical tag choice. Flashing that could trigger photosensitive reactions is a separate concern with its own requirements. A short duration or a generic reduced-motion preference is not a universal safety certificate.
The obsolete blink element is typically inert in current mainstream rendering. A site can therefore have this markup warning without visible movement, while a modern CSS animation can create a real issue without any blink element. Keep those conclusions distinct.
How WebAuditOS evaluates this finding
The supplied axe integration reports visible blink elements and maps serious impact to high severity. Hidden or off-screen cases do not create the same finding under the documented logic. Unrendered pages and untested states remain outside the browser snapshot.
The source also describes a separate compatibility check that can inspect obsolete tags in served HTML regardless of visibility. Neither test is a complete flashing or motion analysis. The configured impact is the rule's report severity, not proof of the real-world risk level of every inert tag.
How to fix it
- Find the rendered element and its source in templates, saved CMS content, or an imported archive. Determine whether any CSS or script adds actual motion independently of the obsolete tag.
- Preserve the intended content using suitable semantic markup. For ordinary emphasis, an illustration is:
<p><strong>Registration closes on Friday.</strong></p>Use strong only when the emphasis is meaningful, not as a universal replacement for every decorative wrapper.
- Move purely visual styling into a maintained class and remove the obsolete element. Check selectors and scripts that previously targeted blink so the message is not accidentally hidden or omitted.
- Prefer static, readable content when motion is not necessary. If an animation is justified, evaluate its real purpose, duration, parallel content, and applicable controls before implementing a replacement.
- Provide usable pause, stop, or hide functionality where required. A hover-only pause is not a complete solution for touch or keyboard users, and a pause that requires holding focus can prevent using the rest of the page.
- Respect reduced-motion preferences as a helpful additional measure. Do not claim that adding one media query automatically meets every motion or flashing requirement.
- Review CSS, scripted animation, background media, and dynamic announcements independently. Do not test potentially hazardous flashing casually; use an appropriate accessibility review process for such content.
- Rescan both accessibility and compatibility checks where applicable, and test narrow layouts, zoom, keyboard focus, and content visibility after replacement.
What the fix can break
Removing the wrapper can change selectors or default inline layout. Verify the text remains readable and appears in the intended position.
Replacing an inert tag with an actual CSS blinking effect can make the experience worse. Modernising the technology does not justify restoring harmful behaviour.
Do not remove important warnings entirely to avoid a motion finding. Communicate their meaning persistently through accessible text and appropriate state design.
Questions
Why is blink flagged when nothing moves?
The supplied rule identifies obsolete visible markup. Current browser behaviour can be static, so evaluate actual motion separately.
Is a CSS replacement automatically accessible?
No. Its behaviour, controls, and flashing characteristics determine the relevant requirements.
Does this finding identify all animation problems?
No. It does not audit every CSS, script, or media motion path.
Which related checks help?
Review obsolete HTML, marquee elements, and the automation limits guide.
What severity does this get in the report?
High. An axe finding takes its severity from the impact axe reports for the element that failed, and the report maps critical and serious to high, moderate to medium, minor to low. axe declares this rule serious, so a failure arrives as high - even though the visible effect in current browsers is small. The panel above shows a conformance level because for axe rules severity comes from the scan.