Performance & Accessibility for Industrial Equipment

Performance & accessibility for industrial equipment means making the pages that sell and support heavy machinery fast, usable and readable by everyone who depends on them: the procurement lead comparing two compact loaders on a desktop, the dealer checking stock between customers, and the field technician standing next to a stalled machine with a phone in one gloved hand, trying to find the right seal kit. For this industry the work is less about a homepage score and more about the parts catalog, the exploded diagrams, the service manuals and the dealer locator, because those are the pages people return to for years after the sale.

This guide follows one illustrative project from start to finish. The company, its site and every number in the project are an example we constructed to show how the work runs; they are not a client story and they are not a promise of results. What is real is the method: how the problems show up on equipment sites, which standards apply, what the parts or service manager has to decide, what the work costs to start, and how you can tell afterward whether it made a difference.

If you run marketing, digital or aftersales for a machinery maker or distributor, the example should map closely onto your own site. If you are a practitioner, the detail on parts diagrams, PDFs, 3D viewers and Interaction to Next Paint is where most of the effort goes.

The illustrative project: a parts site technicians stopped using

Our example company builds hydraulic compact loaders and a line of attachments, sells them through around forty independent dealers, and earns a large share of its margin from replacement parts and service. Its website has four jobs: explain the machines to buyers during a long procurement cycle, let dealers and end users find and order parts, host operator and service manuals, and point people to the nearest dealer.

The trigger for the project was not a traffic drop. It was a pattern the parts and service manager kept hearing from dealers: technicians in the field had given up on the website and were phoning the parts desk instead. They said the parts pages took too long to load on a site with patchy mobile signal, the exploded diagrams could only be used by hovering a mouse over numbered callouts, and the manuals were huge scanned PDFs that could not be searched. Every one of those phone calls cost parts-desk time and slowed the repair.

That framing matters because it sets the success measure. The goal was never a perfect lab score. It was fewer abandoned parts lookups, fewer calls to the parts desk for information the site already held, and pages that people using a keyboard, a screen reader or a small phone could actually use.

Why industrial equipment sites are slow and hard to use

Equipment sites fail in ways that differ from retail or software sites, and the causes are mostly structural. Machines are too large to photograph easily, so marketing teams lean on CAD-based 3D renders, cutaways and animated mechanism explainers. Buyers need to understand how a mechanism works, not just what it looks like, so pages carry video, interactive viewers and configurators. And because procurement is long, the same buyer may come back a dozen times over months, often on different devices.

Heavy media built from engineering files

Renders exported straight from engineering tools are frequently delivered at print resolution. A hero image that was meant for a trade-show banner ends up as the first thing a phone downloads. Interactive 3D viewers bring their own JavaScript runtime and model files that can be many megabytes. Nobody intended the page to be slow; the assets simply arrived at the size the design pipeline produced.

Parts catalogs that grew for years

A parts catalog is usually the largest part of the site and the least designed. It often comes from a separate system, sometimes a legacy electronic parts catalog wrapped in an iframe, with its own scripts, its own styles and its own search. Exploded diagrams are commonly delivered as one large image with an image map or as an SVG where the numbered callouts respond only to hover. Every one of those choices works for a desktop user with a mouse and fails for almost everyone else.

Documentation as scanned PDFs

Operator manuals, service manuals, safety bulletins and spec sheets are often scans of printed documents. A scanned page is a picture of text: it cannot be searched, it cannot be read aloud by a screen reader, and it cannot reflow on a phone. When technicians say they cannot find anything in the manual, this is usually why.

Field conditions nobody tested for

Technicians work outdoors, in bright sunlight, in noisy shops, sometimes with gloves on and often on a weak mobile connection. Small tap targets, low-contrast gray text and pages that need several seconds of script before they respond are not minor irritations under those conditions; they are the reason the phone call to the parts desk happens.

The rules that shape performance & accessibility for industrial equipment

Three sets of rules bear on this work. None of the following is legal advice; it is a practical summary of what a project team needs to keep in view, and your own counsel should confirm how each applies to your products and markets.

Accessibility: WCAG 2.2 as the working target

WCAG 2.2 is the current version of the Web Content Accessibility Guidelines, and Level AA is the target most organizations adopt. Several success criteria bite hard on equipment sites. Non-text content (1.1.1) requires a text alternative for meaningful images, which for a parts diagram means more than an alt attribute that says "diagram." Keyboard (2.1.1) requires every function to work without a mouse, which rules out hover-only callouts. Target Size (Minimum) (2.5.8), new in 2.2, sets a baseline of 24 by 24 CSS pixels for pointer targets, with some exceptions, which matters for the tiny numbered hotspots on diagrams. Dragging Movements (2.5.7), also new in 2.2, requires a single-pointer alternative to drag-only controls, which catches rotate-only 3D viewers and drag-only configurator sliders. Reflow (1.4.10) requires content to work at a width equivalent to 320 CSS pixels without two-way scrolling, except for content such as complex diagrams and data tables that genuinely need two dimensions.

A realistic stance matters here. No audit can make a site "compliant" in a way that ends legal risk, and no overlay widget alone makes a site conformant. What an audit can do is find the barriers, rank them, fix them and set up checks so they do not return.

Safety imagery and OSHA

OSHA requirements shape what may be shown in operation. A product video showing an operator without the required protective equipment, a guard removed for a better camera angle, or someone standing in a pinch zone is not only a bad look; safety imagery that depicts non-compliant practice is a liability in itself. That matters for accessibility work too, because every video needs captions and, where the visuals carry information the audio does not, audio description or an equivalent text alternative. When you write those text alternatives, you describe what is on screen, so the review is a good moment to catch imagery that should never have been published.

Export controls on technical documentation

Export controls can apply to technical documentation. Detailed service data, drawings or software for some equipment categories may be controlled, and publishing it openly on the web can be treated as an export. For accessibility projects the practical consequence is simple: before you convert a restricted service manual into a nicely tagged, searchable, public HTML page, confirm with whoever owns export compliance that it is meant to be public at all. Making a restricted document easier to find is not an improvement.

Scoping the project with the parts and service manager

In our example, the person who signed off every decision was the parts and service manager. That choice was deliberate. Marketing owned the product pages, IT owned the hosting, and a third party owned the parts catalog software, but only the parts and service manager knew how technicians actually used the site: which diagrams got the most lookups, which manuals were requested by phone, and which dealers had complained.

The scoping session answered five questions, and we recommend you answer the same five before any supplier starts:

1. Which journeys matter most? In the example: find a part from a machine serial number, find a part from a diagram, open the right manual, and find the nearest dealer. Product marketing pages came second.
2. Who uses them, on what? The analytics showed a heavy mobile share on parts pages during working hours and a desktop-heavy pattern on product pages, which is common for this kind of business but should always be checked on your own data.
3. What systems are involved? The content management system, the parts catalog software, the PDF library, the dealer locator's map provider and the video host.
4. Who can change what? Some fixes need the parts catalog vendor. Knowing that early changes the plan, because vendor fixes take longer than template fixes.
5. What is off limits? Restricted service documentation, pages under legal review, and anything the dealer agreements govern.

The output of scoping was a page inventory of representative templates rather than a list of every URL. A site with thousands of part pages usually has only a handful of templates, and fixing a template fixes every page built on it. If your team works in sprints, it pays to fold template fixes into normal delivery rather than running them as a separate project.

Measuring the baseline before touching anything

A baseline is what turns "the site feels faster" into evidence. In the example we measured two kinds of data, and it is worth understanding why both are needed.

Field data comes from real visitors on real devices and networks. Google's Core Web Vitals are the common vocabulary: Largest Contentful Paint (LCP) for loading, Interaction to Next Paint (INP) for responsiveness, and Cumulative Layout Shift (CLS) for visual stability. INP replaced First Input Delay as a Core Web Vital in March 2024, and it is usually the metric that exposes heavy parts-catalog scripts, because it measures how long the page takes to respond to taps and clicks throughout the visit, not just the first one. Google's published "good" thresholds are an LCP of 2.5 seconds or less, an INP of 200 milliseconds or less and a CLS of 0.1 or less, assessed at the point where three out of every four visits meet them.

Lab data comes from controlled tests on a throttled device profile. It is repeatable, so it is what you use to check a fix before release, but it is not what your technicians experience. We tested the four key journeys in the lab on a mid-range phone profile and on a desktop, then compared those numbers with field data for the same templates.

Accessibility baselines were built the same way: automated scans across the representative templates, then manual testing with a keyboard, a screen reader on desktop and on mobile, zoom to 400, and a narrow viewport. Automated tools catch a useful share of issues such as missing labels and contrast failures, but they cannot tell you whether a diagram's text alternative is actually useful. The guide to automated accessibility testing covers where those tools stop.

The last figure is worth explaining. In the example, the parts pages carried a tap-to-call link to the parts desk. We counted how many parts sessions ended in that link as a rough proxy for "the site failed to answer the question." It is not a perfect measure, since some calls are legitimate orders, but it is cheap to track and it moves when the pages improve. Treat all four numbers above as an invented example of what a baseline looks like, not as a benchmark for your site.

How the project ran, step by step

With the baseline in hand, the project followed a fixed sequence. The order matters: finding everything before fixing anything prevents the common mistake of polishing the product pages while the parts catalog, where the real users are, stays broken.

Manual testing needs a script so that different testers, or the same tester months later, check the same things. The approach in writing manual accessibility test scripts is the one we used for the diagram and dealer-locator tasks: a numbered task, the expected result, and what counts as a failure.

Fixing the exploded parts diagram

The single most important fix in the example was the exploded parts diagram, because it sits in the middle of the most valuable journey on the site. The original version was a large raster image with numbered callouts. Hovering over a number showed a tooltip with the part name; clicking it added the part to a quote list. It did not work with a keyboard, it was invisible to screen readers, the callouts were far smaller than a fingertip, and the tooltip vanished on touch devices.

The constraint: a text list alongside the image

The fix starts from one principle. Parts diagrams need a text list of part numbers and names alongside the image, so they can be searched and read by assistive technology. The diagram remains useful for sighted users who think visually, but the list becomes the primary, reliable way to identify and order a part. The list also helps everyone: a technician who knows the part name can find it with the browser's find-in-page, and search engines can index part numbers that were previously locked inside an image.

Here is how the text list for one illustrative diagram, a boom cylinder assembly, was structured. The part numbers are invented for the example.

A proper table with header cells lets a screen reader announce "Part number, SK-20045" rather than reading a string of unconnected values. On a phone, the table collapses into a stacked card per row, which is permitted because each row still reads in a sensible order.

Making the diagram itself operable

The diagram was rebuilt as an inline SVG with each callout as a real button. That single change delivered keyboard access, visible focus, a proper accessible name ("Callout 3, seal kit SK-20045") and touch support. Selecting a callout highlights the matching table row and moves focus there, and selecting a table row highlights the callout, so the image and the list act as two views of the same data. Callout targets were enlarged to comfortably exceed the 24 by 24 CSS pixel minimum, and pinch-zoom was left enabled, because on a crowded diagram zooming is how sighted technicians find the small parts.

Manuals, spec sheets and PDFs

The second largest barrier in the example was the manual library. It held several hundred PDFs, most of them scanned, some of them over a hundred pages. Converting everything was neither affordable nor necessary, so we ranked documents by use.

Triage by demand

The parts and service manager supplied a list of the manuals the parts desk was asked about most, and analytics confirmed which PDFs were downloaded most. The top tier, current operator and service manuals for machines still in production, was rebuilt as HTML pages with proper headings, numbered procedures, tables for torque values and fluid capacities, and text alternatives for illustrations. The middle tier, older models still in the field, was remediated as tagged PDFs with real text, a logical reading order, bookmarks and a document title. The bottom tier, discontinued models with little traffic, stayed as scans but gained a short HTML summary page and an offer to provide an accessible version on request.

The detail of tagging, reading order and when HTML beats PDF is covered in PDF accessibility. For equipment documentation, the biggest wins are usually real text instead of scanned images, headings that match the manual's own section numbers, and torque and capacity tables built as tables rather than as images of tables.

Safety content inside manuals

Manuals carry signal-word safety messages such as DANGER, WARNING and CAUTION, typically following the ANSI Z535 conventions for layout and color. When those panels are converted to HTML, the signal word has to be in the text, not only in the color of the panel, and safety pictograms need text alternatives that state the hazard and the instruction. A colored box that says nothing to a screen reader is a safety gap as well as an accessibility one.

Performance for large documents

A 60 MB PDF is a performance problem before it is anything else. Downsampling the embedded images to a sensible resolution, removing duplicate embedded fonts and splitting the largest manuals by chapter made them usable on a mobile connection, while the full compiled document remained available for anyone who wanted to print it.

Performance work on product, configurator and locator pages

Product pages for machinery carry a lot of weight: hero renders, cutaways, spec tables, 3D viewers, mechanism animations and, on some models, a configurator for attachments and options. The fixes in the example followed a clear order.

Largest Contentful Paint

On most templates the LCP element was the hero render. We served it in modern formats at several widths, sized for the viewport rather than for print, and gave the browser an early hint to fetch it. Below-the-fold images were lazy-loaded; the hero was not, because lazy-loading the LCP image delays exactly the thing the metric measures. Render-blocking scripts from a chat widget and two analytics tags were deferred.

3D viewers and mechanism animations

The interactive 3D viewer was the heaviest item on the page. Rather than load it on arrival, the page showed a still render with a clearly labeled button to open the 3D view, and only then fetched the viewer runtime and the model. Model files were decimated to a polygon count suited to the web rather than to engineering. The viewer gained keyboard controls and buttons for rotate, zoom and preset views, which satisfies the single-pointer alternative required for dragging movements. Preparing web-ready models from CAD is a production job in its own right, worth planning separately from the audit.

Mechanism animations were given captions where they had narration, pause controls, and no autoplay with motion over five seconds without a way to stop it. A short text summary of what the animation shows, such as how the hydraulic quick coupler locks, sits under each one; it helps screen reader users, and it helps anyone on a connection too slow for video.

Interaction to Next Paint on the configurator

The configurator recalculated every option, price and compatibility rule on each change, on the main thread. On a mid-range phone, each tap froze the page for over half a second. Splitting the work so that the visible selection updates immediately and the heavier compatibility check runs afterward brought responsiveness within range. Option changes that update the summary were announced through a polite live region, so screen reader users hear "Attachment added: pallet forks" without having their focus moved.

The dealer locator and the forms around it

Dealer locators are map-first by nature, and maps are one of the hardest components to make accessible. The example locator loaded a third-party map on arrival, showed dealers only as pins, and required a drag to move the map.

The rebuilt version put a text search first: enter a ZIP code or city, get a list of dealers with name, distance, address, phone number, opening hours and whether they carry parts, service or both. The map became an optional enhancement loaded after the list, with each pin linked to its list entry. That change removed the map provider's script from the critical path and made the page usable without a pointer at all. Form fields got visible labels, error messages that explain the fix in text, and correct autocomplete attributes so phones can fill in postal codes.

Parts-order and quote-request forms were treated the same way. WCAG 2.2 adds Redundant Entry (3.3.7), which asks that information a user already entered in the same process be auto-populated or selectable, so a technician who entered a machine serial number on step one should not have to type it again on step three. Page titles were also rewritten so every diagram and part page has a unique, descriptive title such as "Seal kit SK-20045, boom cylinder, compact loader parts," which is how screen reader users tell tabs apart.

Timing, seasonality and when to schedule the work

Equipment businesses have busy seasons, and accessibility and performance work should avoid them. Demand for construction and agricultural machinery, and for the parts that keep it running, tends to peak when crews are working outdoors, while trade-show season drives traffic to product and launch pages. The exact calendar depends on your segment and regions, so check it against your own analytics rather than assuming.

In the example, the heavy template work was scheduled for the quieter months, and monitoring ran through the year. Extra checks were triggered by specific events:

• A new release of the parts catalog software or a bulk import of new diagrams.
• Any change to the dealer locator, including a change of map provider.
• A new product launch, which usually brings new renders, videos and a new spec-sheet PDF.
• A site-wide change such as a new consent banner, chat widget or analytics tag.

Keeping gains after the project ends is a habit problem more than a technical one. The approach in making performance a team habit, with budgets for page weight and a check in the release process, is what stops a new 20 MB render from undoing a year of work.

What drove the cost and how to brief a supplier

Performance & accessibility work starts at $1,200.00 per audit with us. That is a starting price; the final figure depends on the size and complexity of what is in scope. The pricing page puts every rate next to what the US market typically charges, and a quote turns the range into one number for your volume.

A good brief makes the quote accurate and the audit faster. Use the checklist below, and if you would rather see how we handle your own material before committing, you can send a couple of your own files, such as one exploded diagram and one manual.

If the audit leads into a redesign or rebuild of the parts experience, the web design and development for industrial equipment page describes how that work runs, and the broader performance and accessibility guide for manufacturing and industrial covers plant-floor and B2B manufacturing sites that share many of the same issues.

The measured result, and how to read it

After the template fixes, retests and technician sessions, the example project was measured again with the same method as the baseline. The figures below continue the same invented example; they illustrate what a before-and-after comparison looks like and are not a forecast for your site.

Reading results like these takes care. Field data lags: Google's field data is reported over a rolling 28-day window, so a fix released today will take several weeks to show fully. Lab numbers move immediately and are useful for confirming a fix, but the field numbers are the ones that describe your users. The click-to-call rate is a business proxy, and it can move for reasons unrelated to the site, such as a new dealer or a recall, so it should be read alongside notes on what else changed that month.

In the example, the drop from 38 to 21 in every 1,000 parts sessions ending in a call means 17 fewer calls for every 1,000 sessions. If the parts pages saw 10,000 sessions in a month, that would be about 170 fewer calls, each of which previously took parts-desk time. That is the kind of arithmetic worth doing with your own numbers, because it links the work to a cost the business already feels.

Accessibility progress needs its own measures beyond a pass count. Tracking open issues by severity, the share of key journeys that pass manual testing, and the time it takes for new issues to be fixed gives a truer picture than an automated score. The article on measuring accessibility progress sets out a practical scorecard.

When you are ready to scope your own project, a quote starts from your template inventory and journeys rather than a generic page count, so the number reflects the work your site actually needs.

Related

Other work for industrial equipment

• Motion Graphics & Animation for Industrial equipment
• 3D Design & Development for Industrial equipment
• E-commerce Development for Industrial equipment
• Web Design & Development for Industrial equipment

Performance & accessibility in other sectors

• Performance & Accessibility for Consumer electronics
• Performance & Accessibility for Sports and outdoor
• Performance & Accessibility for Auto parts and aftermarket
• Performance & Accessibility for Real estate and property

More on performance & accessibility

• How the work runs, what it costs and how we check it
• How to Get Accessible Carousels Right
• A Practical Guide to Accessible Range Sliders

Trying us out

The quickest way to find out if we are any good for you is to send a couple of your own files and look at what comes back. It is free and there is no card involved. If the scope is already clear, ask for a fixed price instead.