Visual meaning and usable tasks

Make the structure carry the meaning.

A page needs more than a convincing screenshot. Its text, images, document order and controls should communicate the same task to people using different devices and ways of navigating.

Free learning from Semantec SEO.

Website page with distinct content and control tiles beside a large cobalt cursor and magnifying glass.

Begin with the information, then choose its form.

A heading identifies the subject of the content that follows. A list groups related items. A table relates consistent criteria across rows and columns. A label identifies a control. These roles should be represented in the page’s markup, not only suggested by font size or color.

The W3C page structure tutorial explains how regions and headings support orientation. Use a logical hierarchy that reflects the intended organization of the content. A large decorative sentence does not need to become a heading simply because it looks prominent.

Desktop and mobile website layouts beside an amber ruler and a blue design cursor.

Identify the main content and distinguish navigation, supporting material and repeated site elements. Avoid duplicate landmarks that make it harder to tell where the page’s main answer begins.

Match the visible page to its document roles.

Semantic HTML describes the job of the content. A heading names the subject that follows; its level expresses its relationship to the surrounding headings. A paragraph can be large or bold without becoming a new topic. Choose the element from that meaning before choosing its visual treatment.

The principal answer belongs in the main content. Repeated site routes belong in navigation. A named group of content can have a heading, while a group of parallel choices can be a list. These are decisions about this page’s information, rather than a fixed set of tags to repeat on every website.

An open folio with heading strips, grouped cards, a grid tile and a curved reading ribbon.

Illustrative page roles and their checks
Visible information	Document role	Check the meaning
The page’s main title	An H1 identifying the page’s subject	The title agrees with the actual answer. Large promotional text does not create another title merely because it is prominent.
A new subject within the answer	A heading nested at the appropriate level	The following content belongs to that subject. Choose the level from its relationship to the other topics, rather than its desired font size.
Parallel choices	A list, or a comparison when consistent criteria are needed	List order does not imply a required sequence unless one exists. A comparison identifies the criteria and the subject of each answer.
Repair options and their arrangements	A data table with a caption and associated headers	Each assessment and request route stays associated with Example A or Example B and its column criterion.
Repeated website destinations	Navigation	The routes can be identified without presenting them as part of the repair explanation itself.
The principal explanation	Main content	A reader can distinguish the answer from the shared header, footer and supporting routes.
A control’s visible wording	An accessible name that matches its action	The label identifies what happens. An action to request review does not claim that an appointment is confirmed.

Correct tags provide useful relationships, but they do not establish that the facts are true, that a control works or that the complete page is accessible. HTML meaning is also distinct from structured data for external consumers. Adding a vocabulary property cannot repair a misleading visible answer. Use structured data learning for that separate implementation task. For the allocation of explanation, examples and actions, organize the full answer.

Hypothetical example: turn a visual comparison into a table.

Imagine two repair options shown as colored cards. Each card contains a provider name, assessment process and appointment method. This is an invented example; it makes no claim about real providers or prices.

If the cards are only a picture, a reader may be unable to select the words, enlarge the text cleanly or understand the comparison through a screen reader. The same content can be expressed in a data table with named columns and explicit row labels.

Magnifying glass over a website page beside a review checklist.

Illustrative comparison of repair options
Option	Assessment	Request route
Example A	Assessment required before the scope is confirmed.	Send the requested details for review.
Example B	Assessment arrangements need confirmation.	Contact the provider to ask about availability.

The wording deliberately avoids unsupported promises. The table exposes the shared criteria, while its caption identifies the hypothetical comparison. On a narrow screen, retain the relationship between each answer and its heading rather than clipping the table.

The W3C tables tutorial explains the relationship between header and data cells. A table should represent data, not be used merely to place unrelated content side by side.

Keep the reading order meaningful.

A desktop layout may place the explanation on the left and an image on the right. On a narrow screen, the content still needs to appear in an understandable sequence. The document order should support the task even when the visual arrangement changes.

Do not move a warning away from the action it qualifies. Do not display a comparison criterion before its subject becomes clear. Check the page with styles reduced and with keyboard navigation; a visual rearrangement can conceal a confusing source order.

A comparison board and open reference book with matching subject motifs.

Use numbered steps when order is necessary. Use an ordinary list when the items are parallel. Do not encode sequence using color alone or assume that “the box on the right” identifies the same content on every screen.

Give images and controls a clear job.

An informative image needs a text alternative that conveys its relevant purpose. A complex diagram can also need an adjacent explanation or data table. Decorative imagery should not create a redundant reading burden.

The W3C images tutorial distinguishes image roles. A generated illustration can support a concept; it should not be presented as a client result, real interface or documentary photograph.

Use ordinary text for the wording readers need to understand or act. Text embedded in an image can become difficult to resize, translate or read. Media titles and filenames help manage assets but do not replace the page’s visible explanation.

Controls need accurate labels and working behavior. “Request an appointment” should not imply confirmation when the business must review the request. A link should open its destination; a button should perform its stated action.

Give each image an honest text role.

Choose the text treatment from the image’s purpose in its actual location. An illustration that helps explain a relationship is informative. A purely decorative flourish adds no information needed for the task. A complex diagram can contain more relationships than a short alternative can convey.

Generated artwork on this page illustrates concepts. It is not a photograph of a client result, an accessibility test or a working interface. The explanation and exact repair comparison remain readable HTML, so their meaning does not depend on interpreting the artwork.

An illustrated folio, a plain cobalt tile and blank cards on a binding ring.

Informative illustration: Describe the relevant subject and relationship in a concise alternative. If a picture helps contrast a visual comparison with readable data, communicate that purpose rather than listing every decorative object. Its meaning still needs to agree with the nearby prose.
Decorative image: Use an empty alternative when the image adds no information or function. Do not repeat nearby text solely to make a decorative picture sound important. Whether an image is decorative depends on its use, not just its appearance.
Complex information: Give a short identification and a complete adjacent text or data equivalent for the relationships a reader needs. A graph or process drawing should not make a reader infer an omitted condition from color or line position. Describe the diagram in readable text when specifying that complete equivalent.
Image used as a control: The accessible name identifies the function, such as opening a particular destination. It should not merely describe the picture while leaving the action unknown. Keep the function and any visible label consistent.

A filename, media title or generated prompt is an asset record, not proof that the displayed image conveys the right meaning. Inspect the delivered file, its crop and its text treatment together. Keep any condition needed to interpret an image in the nearby explanation.

Match the label to an action that actually happens.

A link takes the reader to a destination. A button performs an action. A disclosure reveals or hides its associated content. These controls can look similar while having different meanings and keyboard behavior. Use the appropriate native element, then test the actual implementation.

The examples below act only within this lesson. They do not request an appointment, send a message, store an enquiry or confirm a booking. The repair options continue to describe requests that require review.

An unlettered keyboard key and cursor beside an open hinged card.

A destination link

Read the fictional repair comparison moves to the actual comparison on this page. Its wording identifies the destination rather than promising a service outcome.

A local action button

The button opens a short note using the browser’s native popover behavior. It has no submission service and sends no information.

The same limitation is stated here without opening the note: this example changes only the visible local explanation. If the control does not operate in a particular browser, it is not a working example in that environment and needs an appropriate fallback.

A separate disclosure

Why a request is not a confirmed appointment

Example A asks for details to review; Example B asks the reader to confirm the arrangements and availability. Neither row supplies evidence that a provider has accepted an appointment. A confirmation state needs its own real response and conditions.

For a real enquiry, specify the required inputs, validation, sending, receipt, error and recovery states before presenting the control as operational. Define enquiry and error states. For a calculator, specify its inputs, rules and honest results; a demonstration without a calculation or service must not claim one.

Check behavior as well as appearance.

Review keyboard access, visible focus, labels, contrast, text resizing and narrow layouts against the relevant requirements. The WCAG reference helps identify applicable criteria; a short checklist is not a claim of complete conformance.

Record what was tested, with which browser or assistive technology, and what remains untested. A screenshot can show a visible focus outline, but it cannot prove that every control works or that an error message is announced correctly.

This overview covers visual meaning and structural HTML, including one comparison example. Detailed media, forms, motion, performance and accessibility testing retain their own scope. Return to the learning overview or describe a page that needs review.

Check reading order, focus and recovery together.

A meaningful source order helps reading, but keyboard focus is a related test rather than the same observation. Reading a heading outline does not show whether a button can be operated. A visible focus ring does not show whether an error is announced to a screen reader.

Enter the answer. From the shared skip link, activate the route to the main content and record the actual focus target. Confirm that the reader can identify the beginning of the principal explanation.
Reach the example. Move through the link, action button and disclosure with the keyboard. Record their labels, order and visible focus. Check that warnings remain close to the action they qualify.
Operate each control. Follow the comparison link, open and close the local note, and open and close the disclosure. Record the actual result rather than assuming that a native tag worked.
Recover without losing the task. Check where focus and reading resume after the note closes. For a real form, deliberately test an invalid input and its correction in an authorized test environment; this lesson does not submit a real enquiry or claim to have tested such a form.
Restore the whole context. Read the surrounding explanation again. Confirm that the control result has not separated a warning, prerequisite or limitation from the action.

Record the browser and version, device, keyboard method or assistive technology, expected state, observed state and evidence. A failed action needs a defect record; an action that was not tried remains not run. Use the complete rendered acceptance checks for the wider procedure.

Record acceptance and the work still untested.

Review enlarged text and narrow layouts as well as the default desktop view. Check that words and labels remain readable, media retain their meaning, and each comparison value keeps its associated criterion. On a narrow screen, this lesson presents the table rows as complete labeled records; no value needs to be clipped or reached by horizontal scrolling.

Contrast depends on the actual foreground, background and component state. Check pale records, dark headings, links and open controls in their rendered locations. Automated findings can identify candidates for investigation; label them separately from manual observations and assistive technology results. A screenshot does not establish complete conformance.

The following is a blank acceptance record for a page review, not a claim that these checks have already passed. Replace NOT RUN only with evidence from the named method and environment. Keep FAILED, PASSED and NOT RUN distinct, and record the scope of a pass.

Blank page acceptance record
Requirement	Method and environment	Expected result	Observed result and state	Evidence and remaining work
Keyboard access and focus	Record browser/version, device and the keyboard task above.	Controls can be reached and operated, with visible focus and a useful return position.	NOT RUN; no observation entered.	No capture or operation record supplied. Assign a tester and record every control state.
Text resizing and zoom	Record browser settings and the actual enlargement tested.	Text remains available and readable without losing required content or controls.	NOT RUN; no enlargement recorded.	Inspect long headings, labels, notes and records in the tested configuration.
Narrow layout and order	Record measured content width and device/browser.	Art and explanation stack meaningfully; complete labeled table records fit the available width.	NOT RUN; no width or outcome entered.	Capture each distinct layout and inspect all values, rather than only the first screen.
Text contrast	Record actual foreground/background and normal, focus, open and error states where present.	Applicable contrast requirements are met for the actual text and state.	NOT RUN; no measurements entered.	Record the measured pair, requirement used and any unresolved rendering condition.
Labels and relationships	Inspect headings, regions, accessible names and table header associations.	The programmatic role and name communicate the same task as the visible content.	NOT RUN; no inspection entered.	Check repeated labels and every narrow record’s relation to its original criterion.
Assistive technology	Name the actual assistive technology/version and browser, with a defined reading and operation task.	The tested task can be understood and completed, including any announced state or error.	NOT RUN; no assistive technology session performed.	Retain any issue or untested combination. Other checks do not substitute for this evidence.

A usable answer also depends on reaching the page. Check technical access for that distinct dependency. Detailed forms, motion, media, diagrams and reading effort keep their own complete methods; this record does not replace them.

Related resources can have their own review work outstanding. This overview does not establish that the whole learning branch is complete or accepted.

Run the rendered acceptance checks: Test the current page’s content, controls, keyboard behavior and narrow layouts; retain the actual environment and any untested requirement.
Make the page task apparent: Specify which answer must be prominent, then check that artwork and layout do not displace its explanation or conditions.
Keep image and text within the same claim: Compare the finished visual with its adjacent wording, including the limit that prevents a broader inference.
Preserve the diagram’s relationships in text: Record every relationship needed to understand the diagram and provide a complete readable equivalent.
Build comparisons with clear headers: Specify the criteria, row subjects and honest gaps before choosing a readable comparison layout.
Specify real inputs, rules and outputs: Define the actual calculation or service, unavailable states and observed output; a decorative demonstration is not a working tool.
Define enquiry and recovery states: Keep a request, sending attempt, receipt, error and confirmation separate in the interface’s wording and behavior.
Organize the complete answer: Allocate explanation, examples and actions to the task without dropping the conditions a reader needs.

Check the access dependency too.

Use technical access and indexing for crawl controls, indexing evidence and the limits of a URL inspection result.