Podcast E653 – Accessibility After Launch  🔗 **Source:** [Podcast E653 – Accessibility After Launch](https://share.snipd.com/episode/5edab510-a2c0-4a2c-ab10-20c6d32f5af9) ## Highlights - **When Accessibility Became Personal** - Adam Philby’s changing eyesight and ocular migraines made contrast, type size, motion, and visual effort immediate accessibility concerns. - He emphasizes that his experience does not represent everyone with disabilities, but illustrates how user needs can change suddenly or gradually. Transcript: Adam Philby My eyesight has changed quite a bit over the, weird to say this, two decades in WordPress. And more recently, I've had to deal again with some issues with ocular migraines. And sometimes I just can't look at a computer. So, you know, it's not fun. So anyway, you know, contrast, type, size, motion, focus, visual effort feels much less theoretical to me now than it used to. I mean, it's the reality of getting older sometimes, I guess. But on a difficult day, it can really determine whether a sight feels comfortable or exhausting from my perspective. My experience does not, again, keep in mind, represent everyone with low vision, migraines, or another disability. It's just the accessibility issue is much broader than just eyesight. But it reminded me how fragile our idea of the average user can be. So people's abilities, environments, devices, and needs change over time. It happens gradually. It can happen for a temporary time. ([Time 0:02:45](https://share.snipd.com/snip/ae5080e3-b617-4bf3-8bfd-8cb24b5fa3a4)) - **Launch Accessibility Is Not The Finish Line** - A site that launches accessibly can deteriorate as content, plugins, forms, promotions, and staff practices change. - An audit captures one moment, while maintenance continuously identifies barriers and verifies that fixes work. Transcript: Adam Philby All right, so here's the big idea for today. An accessible launch is not an accessible finish line. We know a website can be is often carefully designed. It's reviewed. Ideally, it's tested before launch, but then it can become harder to use a month or six months or years later. Someone publishes a rush page. A plug in changes its markup. A new form gets added. A promotion introduces low contrast colors, a video gets posted without captions, a new staff member inherits the website without any accessibility training. Now, as a semi-retired photographer videographer, I'm going to say that an audit is a snapshot. Maintenance is the movie. The goal is not to claim permanent perfection. The goal is to build a routine that helps us notice barriers, fix them, confirm that the fix actually worked because that's the key here. ([Time 0:03:43](https://share.snipd.com/snip/2d152c3d-e284-4890-9d06-4228a733835b)) - **Scan Representative Pages Every Month** - Scan representative pages monthly, including forms, purchases, registrations, and conversion pages. - Treat automated results as leads rather than proof, because human judgment catches barriers scanners cannot detect. Transcript: Adam Philby Okay, first checkpoint, scan the site every month. The way to do this would be using an automated accessibility checker on a small but representative group of pages that might include the homepage, a normal article, a landing page, And a form. Don't leave out purchases, registration, or a conversion page if your site has one. The scanner can help catch things like missing labels, empty links or buttons, contrast warnings, heading problems, images without the alt text. It's really useful when the same mistake appears across templates or gets repeated by a content workflow. But this is the important thing here. An automated tool is a smoke alarm, not a building inspector. You can alert to possible trouble. It cannot look at the entire experience and declare the website accessible. Some results need human judgment. Many do, and many barriers cannot be detected automatically at all. Also, don't become obsessed with one score, one rating. ([Time 0:04:38](https://share.snipd.com/snip/9483b8c2-4be0-49ac-a592-c956c5f47cbb)) - **Test Accessibility Without Your Defaults** - Test with a keyboard, 200% zoom, contrast checks, and reduced-motion considerations instead of relying on normal mouse use. - Look for invisible focus, broken tab order, clipped content, scrolling, small targets, glare, and exhausting motion. Transcript: Adam Philby All right, checkpoint number two, experience the site without your usual defaults, meaning put the mouse aside for a few minutes at least, use the keyboard, press tab and move through The page. Can you tell where you are? Does the focus indicator remain visible? Does the order make sense? Can you open and close menus, reach buttons, reach form fields, dismiss pop-ups? You get the gist here, right? Then zoom to 200%. Look for cutoff text, overlapping controls, unwanted horizontal scrolling, or content that becomes confusing. Check the contrast. Thank you very much. Check the instructions that depend on color, distinguishable links, and usable target sizes. Also note sliders, autoplay, animation, flashing, and dramatic transitions. Ask whether motion can be paused, stopped, or reduced. As I said earlier, my eyesight and migraines have changed my perspective here. Something that can be technically visible and still require too much effort is not great. Low contrast, glare, dense text, small targets, and motion all add up. Accessibility is also about avoiding unnecessary friction and the fatigue that it brings on. So do a short version of this check every month and expand the sample every quarter. ([Time 0:05:39](https://share.snipd.com/snip/39b76d56-10f3-4655-af33-d8bcf7da501b)) - **Test The Tasks Visitors Actually Need** - Identify the three tasks visitors most need, then complete each with keyboard navigation and intentional form errors. - Verify labels, error messages, confirmations, emails, transactions, captions, transcripts, and media controls across the entire journey. Transcript: Adam Philby Instead of testing random pages forever, identify the three things people most need to accomplish on the site. That might be contacting the business, submitting a form, purchasing or downloading a product, registering for an event, searching for information, or playing the latest podcast Episode. Then actually complete those tasks. Try using the keyboard. Confirm the form fields have labels that remain available after you start typing. Trigger a few errors intentionally. Does the error message explain what happened? Does it identify the field that needs attention? Can you find the message without scanning the entire page visually? Follow the journey beyond just submit. Is the confirmation understandable? Does the email arrive? Can someone tell whether the transaction succeeded? For audio and video, check that that controls and the appropriate transcripts or captions are there. Every individual component may look acceptable while the full task remains confusing or impossible. ([Time 0:06:50](https://share.snipd.com/snip/eea739a2-dc83-4794-991e-d9303e99a5dd)) - **Retest Accessibility After Every Major Change** - Retest meaningful changes to WordPress, plugins, themes, navigation, forms, blocks, or page-builder modules before production. - Compare before and after, document reproduction steps, and make accessibility part of the definition of done. Transcript: Adam Philby Retest whenever the site changes in a meaningful way. Accessibility can drift after WordPress core gets updated, plugins or theme gets updated, a new Beaver Builder module or block or navigation form. Something can happen in that setting there. The rule is simple. Test what changed and one important workflow next to it. A navigation call for a keyboard test. A form update calls for successful failed submissions. A design change calls for contrast focus and zoom for responsiveness. Whenever possible, do this before the change reaches production. Compare before and after. I mean, it's not that hard to do. Save a screenshot when it helps. Write down concise reproduction steps so someone else can see the same barrier. Most importantly here, make accessibility part of the definition of done. If accessibility is always a separate cleanup project scheduled for later, later has a habit of never arriving. ([Time 0:07:56](https://share.snipd.com/snip/a2915b3d-2a4d-4062-b34b-333c083b7669)) - **Give Every Accessibility Issue An Owner** - Assign every issue a severity, owner, target date, affected component, reproduction steps, user impact, and retest result. - Consider a barrier unresolved until verification proves it disappeared without breaking another workflow. Transcript: Adam Philby Okay, checkpoint number five, give every issue an owner and a finish line. A report containing 50 warnings is not a maintenance plan. Someone needs to decide what matters first, who's responsible, and when the result will be checked again. Using a simple severity system, you know, an urgent issue blocks an essential task. Perhaps the menu can't be used by a keyboard, checkout cannot be completed, or required field has no usable label. That needs immediate attention or an accessible alternative. A high priority issue seriously impedes a common task or appears in a repeated component. A routine issue is localized, has a workaround, but still needs a date and an owner. Okay, for each issue, record the affected page or component, the steps needed to reproduce it, the user impact, the owner, the target date, and the result of the retest. And here's a part that teams often miss. The issue is not finished when someone changes the code or content. It's finished when someone verifies that the barrier is gone and confirms that the change did not break something else. ([Time 0:08:49](https://share.snipd.com/snip/e821dbc2-d637-4b6e-80ba-5cac5762f0a6))