Semantic HTML
// Definition
The practice of using HTML elements according to their intended meaning — heading elements (h1–h6) for headings, button for interactive controls, nav for navigation regions, main for the primary content area — rather than using generic div and span elements for everything. Semantic elements convey role, structure, and sometimes state to browsers, search engines, and assistive technologies without requiring additional ARIA attributes. QA testers check that pages use a logical heading hierarchy, landmark regions are present, and interactive controls use native elements rather than div or span with click handlers.
// Related terms
ARIA (Accessible Rich Internet Applications)
A W3C specification that adds roles, states, and properties to HTML elements to expose semantics to assistive technologies when native HTML alone is insufficient. The first rule of ARIA is: do not use ARIA — prefer native HTML elements (button, input, nav) that carry the correct semantics implicitly. Incorrect ARIA can make an interface less accessible than no ARIA at all. QA testers check that ARIA roles match the component's actual behaviour, required states (aria-expanded, aria-selected, aria-checked) update dynamically, and aria-label or aria-labelledby provides meaningful names for elements that lack visible text.
DOM
The Document Object Model — a tree-shaped, in-memory representation of an HTML (or XML) document that the browser builds after parsing the page source. Each element becomes a node, and JavaScript (and test tools like Playwright and Selenium) interact with the page by traversing and manipulating this tree. Understanding the DOM is essential for writing stable locators: a query like `#submit-btn` targets the DOM node, not the raw HTML string.
Accessibility
The practice of designing and testing software so it is usable by people with a wide range of abilities — including users who rely on screen readers, keyboard navigation, voice control, switch access, or high-contrast display modes. In QA, accessibility testing involves both automated scanning and manual verification. Automated tools (axe, Lighthouse, Accessibility Scanner for Android, Accessibility Inspector for iOS) catch structural issues such as missing labels, insufficient colour contrast, and incorrect ARIA roles — typically around a third of all accessibility issues. The remaining two-thirds require testing with actual assistive technologies: VoiceOver on iOS, TalkBack on Android, NVDA or JAWS on Windows. WCAG 2.1 AA is the most widely referenced standard; Level AA compliance is required by law in many jurisdictions (ADA, EN 301 549, AODA). Integrating accessibility checks into CI — for example, running axe as part of a Playwright or Selenium test suite — prevents regressions from being merged undetected.