An industrial website accessibility checklist should cover six areas: navigation and keyboard operation, forms and error handling, product tables and filters, technical documents, media and diagrams, and the publishing routine that keeps it all in order after launch.
WCAG 2.1 AA and EN 301 549 are the references most European organisations work to. Whether the European Accessibility Act or national legislation applies to your organisation depends on your products, markets, customers and size, and that determination should be confirmed with qualified legal counsel rather than inferred from a checklist. The engineering case for the work stands regardless.
Work through the routes a buyer, distributor, engineer or applicant needs to complete: finding a product range, comparing specifications, downloading a datasheet, submitting an enquiry, locating a distributor and reaching any private area.
Operate each with the keyboard alone and then with a screen reader. Focus order, visible focus, skip links, accessible names on controls and comprehensible error messages matter more on those routes than anything on the homepage.
Specification tables need proper header markup with scope, captions that explain the content, and a horizontal scroll region that is reachable by keyboard. Values conveyed only by an icon or a colour need a text equivalent.
Product finders and faceted filters need particular care: announce how many results a selection returned, keep focus in a sensible place after an update, and make sure the state can be reached without a pointing device. These components are reused across the whole catalogue, so a single defect scales to every product page.
Where a datasheet, installation guide, safety document or certificate is required to evaluate or use a product, it forms part of the experience. Check that PDFs have a document title, a logical reading order, real text rather than a scanned image, tagged headings and tables, and a stated language.
Where a supplier-issued document cannot be remediated, publish the essential specification as HTML alongside it. That serves accessibility and search visibility at once.
Industrial sites lean on dimensional drawings, exploded views, process schematics, performance curves and installation photography. An alternative text repeating the file name serves no reader; a diagram carrying information needs a description that conveys it, with a longer text or table equivalent where the detail is substantial.
Video needs captions and, where the visual content carries information the audio does not, an audio description or an accompanying transcript.
Check heading order, link text that makes sense out of context, contrast ratios including on brand colours and disabled states, text resizing to 200 per cent, and reflow at narrow widths. Technical content should stay comprehensible when images or styles are unavailable.
Fix defects in the design system rather than page by page. One inaccessible accordion, modal or filter component affects every template that reuses it, which is set out further on our website accessibility page.
Automated tooling catches a portion of issues and manual keyboard and assistive-technology testing is required for the rest. Record each finding with its user impact, an owner and a retest date, and keep an accessibility statement that reflects the current position accurately.
Then give editors and document suppliers simple publishing rules. Accessibility holds where it becomes part of product-page creation, document publishing and release quality assurance rather than an annual audit.
Six areas: navigation and keyboard operation, forms and error handling, product tables and filters, technical documents such as datasheets and certificates, media and technical diagrams, and the publishing routine that maintains all of it. Test representative templates and the key buyer journeys rather than sampling pages at random.
WCAG 2.1 AA is the usual working target, and EN 301 549 is the European standard that references it. Whether a specific legal obligation applies to your organisation depends on your products, markets, customers and size, and should be confirmed with qualified legal counsel. Working to AA is a defensible engineering baseline in either case.
Where a datasheet, installation guide, safety document or certificate is needed to evaluate or use a product, it forms part of the experience. Check for a document title, logical reading order, real text rather than scanned images, tagged headings and tables, and a stated language. Where a supplier document cannot be fixed, publish the key specification as HTML alongside it.
Use real table markup with header cells and scope, add a caption explaining what the table contains, and make any horizontal scroll region keyboard reachable. Values shown only through an icon or colour need a text equivalent. Because these tables are generated by a shared template, correcting the pattern once fixes the whole catalogue.
No. Automated tooling reliably finds a subset of code-level issues such as missing alternative text, contrast failures and unlabelled controls. It cannot judge whether an alternative text is meaningful, whether focus order makes sense, or whether a product finder can be completed with a keyboard. Manual testing is required alongside it.
It can, and it is markedly cheaper to define accessible patterns before templates and catalogue content are multiplied. Where a site is already live, a focused audit can establish priorities, after which fixes are best made in the design system so that every template inheriting a component improves at once. Then update the publishing rules so it holds.
We can assess the templates, technical documents and governance model behind your website.