Frontend systems

Semantic markup treats the browser's built-in elements as reusable behavioral components. A form associates labels with controls and establishes submission semantics. Required fields, input types, descriptions, and error messages can be exposed consistently across browsers and assistive technologies. A search input does not become an accessible search interface merely because the designer placed a magnifying-glass icon beside it. Use a form with a meaningful action, a labeled input, and a button that submits. A link should navigate to a resource; a button should initiate an action on the current page. Misusing one for the other creates problems with keyboard behavior, expected context menus, and automated testing.

Semantics also constrain the software design. A lesson with a chapter title, a summary, sections, figures, and a references list can be represented using ordinary document hierarchy. The DOM becomes more predictable, so CSS can target components through stable classes and scripts can operate on actual controls. A disclosure widget can use details and summary for a simple question solution; a more complicated dialog needs focus entry, focus trapping where appropriate, escape behavior, and focus restoration. Choosing the right native structure reduces custom code, but does not guarantee the entire interaction meets accessibility guidelines.

Imagine an online admission exam with 40 questions and a timer. Mark each question group as a fieldset with a legend; use radio buttons for one-of-many choices, and provide clear state on whether an answer has been saved. A page-level banner showing remaining time should not continually interrupt screen readers. Offer an explicit warning before expiration and support alternative arrangements where required. A mouse-only grid of unlabeled numbered circles may look efficient while denying some users a workable exam. Semantic structure helps test these failure modes before students rely on the service.

HTML validation is necessary but insufficient. A syntactically valid button can still say 'click here' without context, submit a form by accident, or disappear behind a sticky panel. Inspect the accessibility tree, tab order, link destinations, and form errors. Use language declarations and meaningful page titles. Ensure each image has an alternative suited to its purpose: a purely decorative gradient may need an empty alt attribute, while an equation image requires equivalent mathematical information. Source order and names should survive without CSS. This is a practical definition of robust markup.

Applied design, experiment, and interpretation

Case analysis: a timed exam form. A student answers multiple-choice questions, navigates between sections, and receives a final confirmation. Each group of radio options belongs to a fieldset, with a legend that communicates the question. Selecting an option should not silently submit the exam. The submit button must be distinct from navigation buttons, and the current progress indicator must have text rather than just a green ring. Form validation can explain unanswered mandatory questions while respecting any assessment rule that allows blanks. An accidental page refresh should not erase already confirmed answers.

Research exercise. Use only a keyboard to select an answer, jump to the next question, review the summary, and submit. Confirm that the focus destination is predictable after a validation error. Test with the page zoomed and narrow. Check that a timer warning is perceivable without causing a live announcement every second. Browser form semantics solve some baseline problems, but they cannot decide the exam's business rules.

CSS describes presentation constraints over a document tree. The cascade resolves values from origin, importance, layers, specificity, and source order; inheritance passes some properties to descendants. Developers frequently treat the last stylesheet rule as automatically dominant, but a highly specific selector or important declaration may override it. A maintainable design system deliberately chooses component boundaries, tokens, and layer precedence so that one change does not require a cascade of emergency overrides. Layout primitives should fit the relationship: flexbox is suited to distributing items along one main axis, while grid can establish two-dimensional tracks. Neither should replace semantic HTML.

Responsive design begins with content constraints rather than device-name breakpoints. An article can use max-width measured in readable characters; a visualization can occupy an available grid column; controls can wrap when their minimum usable size is threatened. A sidebar that looks fine on a wide screen may leave an article with only 180 pixels on a tablet. Use minmax(0,1fr) to allow a grid child to shrink and min-width:0 for containers with long code or tables. The visible result depends on font size, language, zoom, and user preferences, so checking only one mobile screenshot is not a reliable responsiveness test.

A common failure is cumulative layout shift. An image without reserved dimensions loads and pushes the text beneath it; an embedded simulation resizes after JavaScript initializes; a banner inserts content above the current reading position. Reserve aspect ratios for images and simulation slots, load fonts responsibly, and measure the experience under slower connections. Color contrast and focus visibility must work in all themes. Do not rely on color alone to show correct answers; include icons, labels, and explanatory text. Respect prefers-reduced-motion in transitions that might otherwise create vestibular difficulties.

The design-review process should include edge cases rather than only the intended desktop. Test long university names, translated labels, error messages, mathematically formatted content, and a browser at 200 percent zoom. Ask whether a touch target remains usable after layout changes, whether a fixed footer obscures the submit button, and whether overflow permits a code sample to scroll independently. CSS is most reliable when driven by explicit content contracts and measured usability, not by treating every viewport width as a new visual mockup.

Applied design, experiment, and interpretation

Case analysis: layout under translation and zoom. An academic catalog works at 1280 pixels but overflows on a phone when the navigation labels expand in another language. The root cause is a rigid two-column grid with a non-shrinking content child and fixed-width tabs. A better layout uses responsive minmax columns, wraps the navigation, and constrains tables or code blocks to scroll within their own regions. A long chemical equation should never force the entire page wider than the viewport. Reserve a stable geometry for interactive simulations. Ensure focus outlines are not clipped by overflow containers.

Research exercise. Capture the same page at 320, 390, 768, and 1280 CSS pixels, then repeat at increased zoom. Record horizontal body overflow, hidden actions, and input target size. Audit computed layout rather than only CSS declarations. When fixing an overflow bug, verify that the table remains readable and that the remedy did not shrink text below a usable size.

Client state is information the browser needs to present an interaction; it is not automatically the authoritative record. A simulation slider position, currently expanded explanation, and selected tab can live entirely in local component state. A shopping basket may be synchronized with a server. An authenticated user's role must be enforced on the server even if it appears in client state. Confusing display state with trusted business state creates both correctness and security problems. A disciplined frontend identifies which state is ephemeral, which must survive navigation, which can be reconstructed from a URL, and which requires server confirmation.

Consider an editor for laboratory notes. The user changes a paragraph, triggering an optimistic local update and a background save. If the network fails, the UI should preserve the unsaved draft and display an actionable status. If the same document is open in two tabs, later writes can overwrite earlier edits unless the service uses revisions or a conflict strategy. A timestamp alone is not a safe universal merge algorithm. For a simple single-user editor, an If-Match precondition based on an ETag can reject a stale update; for collaborative editing, operational transformation or conflict-free replicated data structures may become relevant, but they add substantial complexity.

Derived state should generally be calculated from canonical inputs rather than copied into multiple variables. Suppose a test interface stores both 'answers' and 'answeredCount' independently. A code path that updates one but not the other produces inconsistent progress displays. Prefer computing the count from the answers collection, or update both through a well-defined reducer with invariant checks. Asynchronous responses create races too: a slower search request for 'ca' might arrive after a faster request for 'calc'. Track request versions, cancel obsolete operations when possible, and ensure that a stale result cannot replace current data.

State debugging benefits from event timelines. Record user actions, action identifiers, expected transitions, and server acknowledgments without exposing private data. In a reproducible test, put the UI into a defined initial state, exercise one event sequence, and assert final visible behavior. Local storage is convenient for non-sensitive preferences, but it is accessible to scripts on the origin and should not hold secrets. Rehydrating persisted state must validate its schema, because browser data may be outdated or user-modified. The central lesson is to keep one reliable source of truth for each type of information.

Applied design, experiment, and interpretation

Case analysis: conflicting search requests. A user types 'ther', then rapidly types 'thermo'. The request for the shorter query reaches the server first but returns after the longer query. If the UI renders whichever response arrives last, it may show unrelated results while the input displays the new term. Give each request a monotonically increasing version and render only the response belonging to the latest active query, while cancelling obsolete fetches when possible. Store the query in the URL only when sharable search state is intended. Keep unsaved form data separately from results so that search updates cannot erase input.

Research exercise. Introduce artificial response delays and assert that old results never replace current ones. Navigate backward and confirm that the query and rendered results converge on the restored URL. Reload with corrupt local preferences and verify a safe default. Compare a derived result count against a separately maintained counter to see why redundant state can diverge.

Accessibility is an engineering property of the entire interaction, not a checklist applied after design. WCAG 2.2 describes testable success criteria for perceivability, operability, understandability, and robustness. Compliance claims require evaluation against relevant criteria and context; a single automated score is not enough. People may navigate with a keyboard, switch, screen reader, voice input, magnification, or touch. Many users have combinations of needs that automated tools cannot model. Building an accessible science simulation requires both technical controls and a text explanation of the phenomenon.

A graph of electric potential illustrates the challenge. The browser canvas might draw a smooth curve, but a blind student cannot infer its peak and zero crossing from pixels alone. Supply a sentence such as 'Potential increases to its maximum near the center and decreases toward the right boundary' and a tabular set of significant values. Give each parameter slider a label, range, units, and accessible current value. A reset control should restore values predictably and announce completion without reading the entire graph on every frame. Keyboard users must be able to operate controls and leave the simulation. Motion and color choices should not be the only way to perceive an outcome.

Focus management frequently causes real failures. A dialog opens while focus remains behind it; a result notification appears but cannot be reached; a button disappears on submission and focus falls back to the page root. For a modal dialog, set an initial focus target, keep focus contained while modal interaction is active, close on expected escape behavior, and restore focus to a sensible trigger. For an inline alert, decide whether a live region is necessary or whether a persistent, visible error summary will serve better. Aggressive announcements can make a simple experience exhausting.

Manual tests should complement scanners: navigate every form with the keyboard, zoom without loss of information, inspect headings and landmarks through a screen reader, and repeat with reduced motion. Test invalid form states and long content, not just a happy-path homepage. Screen-reader behavior differs by browser and platform, so document the combinations used. Accessibility work often exposes deeper design errors: an unlabelled control may reflect an unclear conceptual model; an impossible tab order may reveal that the layout contradicts task sequence. Addressing these root causes benefits every learner.

Applied design, experiment, and interpretation

Case analysis: an interactive force diagram. The diagram draws a vector arrow on canvas, changing length as a slider moves. A sighted user sees the result, but a reader using a screen reader hears only 'slider 50'. The control must specify force magnitude, units, permitted range, and current value. The output should say how the resultant direction and magnitude changed, ideally with a text-based summary of vector addition. Keyboard adjustment and reset must work. The design should not rely only on red and blue colors to distinguish forces. Reduced-motion preferences may suppress unnecessary animation while keeping essential information available.

Research exercise. Complete the same learning task without looking at the canvas. Check the reading order, control announcements, and textual interpretation of maximum and minimum inputs. Use a keyboard-only pass to identify focus traps. Test an invalid value and decide how the interface communicates that it has been rejected. The objective is equivalent access to the concept, not identical pixel experience.

Integrated laboratory: an accessible offline-friendly study reader

Implement a small study reader containing a course title, an ordered chapter navigation, two text sections, one worked question, and one interactive numeric model. The initial markup must contain the educational prose directly. Use semantic landmarks and heading levels so that someone navigating by headings can identify the current unit. Place a labelled input and an output sentence beside the simulation. The control's initial value, range, step size, and units should all be clear before any script executes. A button is an action, not a hyperlink styled as an action; the chapter navigation should remain ordinary links.

Write down your state model. The active page is represented by the URL. The currently expanded answer is transient display state. The simulator slider is local state that can be reset. Optional reading preferences may be stored locally with validated defaults. A student's official quiz grade is authoritative server state and must not be computed solely from local client variables. Propose what happens when an asynchronous fetch for supplementary resources fails. Essential explanations should remain visible, and a concise error message should explain which optional enhancement is unavailable.

Use CSS grid for the large-screen reader and a single-column flow for narrow screens. The sidebar must not trap the main content in a 150-pixel column. Reserve a bounded area for the diagram and allow long code examples to scroll within their own containers. Test at 320 and 768 CSS pixels as well as a conventional desktop width, and increase browser zoom. A responsive interface does not merely hide a navigation panel; it must preserve the ability to find chapters, submit answers, and read mathematical text. Check keyboard focus outlines after every viewport change.

Run a keyboard-only walkthrough. Navigate to a chapter, focus the model slider, adjust it using arrow keys, read the output, reset it, and reveal a worked solution. The reveal mechanism must expose its expanded state and allow the student to return to their reading position. Repeat with reduced motion enabled. Open the accessibility tree and identify whether control names and heading relationships remain meaningful. Automated accessibility scans can flag many errors, but this task needs a manual check of the actual learning interaction.

Finally disable JavaScript. The article, navigation, and worked explanation should remain readable; the simulator can fall back to a static example with documented values. Report what changed and why. This design separates the durable public content from optional dynamic capability. It also yields clear tests: content existence, navigation, input state, output correctness, reset behavior, responsive layout, and keyboard operation. Add a brief risk note explaining why a high accessibility score alone is not proof that the scientific explanation can be understood without a visual graph.

Synthesis: the accessible frontend as a set of explicit contracts

A browser interface joins a semantic document, visual layout, interaction state, and asynchronous data flows. None can compensate automatically for errors in another layer. A correctly styled button can have the wrong action semantics; a valid DOM can have an inaccessible focus sequence; a logically consistent state reducer can still reveal private data if the server fails authorization. Design begins with the learner's actual task: read an explanation, adjust a simulation, interpret the output, save a response, and resume after an interruption. Only then should layout tokens, libraries, and animations be chosen.

To connect the topics, follow one simulation interaction. The button or slider receives input through semantic HTML, local state tracks the current parameter, a calculation produces a displayed value, CSS makes the result usable on a narrow viewport, and assistive information communicates the same scientific concept. If a network request loads supplementary data, its completion must be reconciled with the latest user intent. Tests should cover all of these transitions. A reader who cannot see a canvas still needs a valid mathematical explanation. A student using a slow device should be able to read while nonessential code initializes. These are not separate polish tasks but requirements of the same learning contract.