{"dataset":{"id":"00000000-0000-0000-0000-000000000037","slug":"accessibility-best-practices","name":"Web accessibility best practices","description":"Source-linked guidance on web accessibility fundamentals: semantic HTML, the first rule of ARIA, keyboard operability, color contrast, and form labels. Scoped to web accessibility; not a WCAG conformance checklist.","visibility":"public","version":1,"documentCount":5,"publisher":"Koskamo editorial","license":"Original summaries; linked sources retain their own terms.","reviewedAt":"2026-10-04T00:00:00.000Z","readOnly":true,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},"total":5,"documents":[{"title":"Accessible form labels","sourceUrl":"https://www.w3.org/WAI/tutorials/forms/labels/","text":"Provide labels to identify all form controls, including text fields, checkboxes, radio buttons, and drop-down menus; in most cases this is done with the <label> element, and labels need to describe the purpose of the control. A label and its form control should be associated with each other either implicitly or explicitly. Prefer explicit association: the for attribute of the label must exactly match the id of the form control. Association matters because browsers expose the label as a larger clickable area for selecting or activating the control, and because it lets assistive technology refer to the correct label when presenting the control. Where the purpose of a control is already clear from the visual context, the label can be hidden visually, but it still needs to be present in the code and associated, so that screen reader and speech input users get the same identification. Scope: Web accessibility. Reviewed October 4, 2026.","id":"accessibility-best-practices:Accessible form labels","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"Color contrast ratios","sourceUrl":"https://developer.mozilla.org/en-US/docs/Web/Accessibility/Guides/Understanding_WCAG/Perceivable/Color_contrast","text":"The color contrast between background and foreground content — usually text — must be great enough to ensure legibility. WCAG recommends minimum contrast ratios by content type: body text needs 4.5:1 for an AA rating and 7:1 for AAA; large-scale text (120-150% larger than body text) needs 3:1 for AA and 4.5:1 for AAA; active user interface components and graphical objects such as icons and graphs need 3:1 for AA, with no AAA ratio defined. These ratios do not apply to incidental text such as inactive controls, logotypes, or purely decorative text. Good contrast benefits every user, but it particularly helps people with color blindness and similar conditions who experience low contrast and have trouble differentiating similar colors, because they do not see bright and dark areas as readily and therefore struggle to see edges, borders, and other details. Scope: Web accessibility. Reviewed October 4, 2026.","id":"accessibility-best-practices:Color contrast ratios","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"Keyboard accessibility and focus order","sourceUrl":"https://developer.mozilla.org/en-US/docs/Web/Accessibility/Guides/Understanding_WCAG/Keyboard","text":"To be fully accessible, a web page must be operable using only a keyboard, which matters for screen reader users, people who have trouble operating a pointing device such as a mouse or trackball, and anyone who prefers keyboard input. Focusable elements should have interactive semantics: if an element can receive keyboard focus, the user should be able to do something with it and produce a change, such as activating a link or changing an option. Most interactive elements are focusable by default; adding tabindex=\"0\" makes another element focusable in the default focus order, but only do so when you have also made it interactive, for example by defining appropriate keyboard event handlers. Avoid tabindex values greater than zero: a positive value pulls the element ahead of the default order, which follows the HTML document, creating confusion for keyboard-only users when the focus order differs from the logical order of the page — structure the HTML so focusable elements are already in a logical order instead. Scope: Web accessibility. Reviewed October 4, 2026.","id":"accessibility-best-practices:Keyboard accessibility and focus order","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"The first rule of ARIA","sourceUrl":"https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA","text":"The first rule of ARIA use: if you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state, or property to make it accessible, then do so. The companion saying is \"No ARIA is better than bad ARIA\": in WebAIM's survey of over one million home pages, pages with ARIA present averaged 41% more detected errors than those without, because ARIA used incorrectly can do more harm than good. When no native element fits — as with a progress bar built on a meaningless <div> — add the missing semantics with role=\"progressbar\", aria-valuemin, aria-valuemax, and aria-valuenow, and keep aria-valuenow updated with JavaScript as the value changes so assistive technologies announce the current state. Scope: Web accessibility. Reviewed October 4, 2026.","id":"accessibility-best-practices:The first rule of ARIA","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"Semantic HTML first","sourceUrl":"https://developer.mozilla.org/en-US/docs/Learn_web_development/Core/Accessibility/HTML","text":"Use semantic HTML — sometimes called Plain Old Semantic HTML (POSH) — by choosing the correct element for its intended purpose. A control marked up as a bare <div> can be made to behave like a button with CSS and JavaScript, but a real <button> comes with suitable default styling and built-in keyboard accessibility: users can move between buttons with the Tab key and activate them with Space, Return, or Enter. Semantic markup takes no longer to write than non-semantic markup when done consistently from the start of a project, and it carries benefits beyond accessibility: it is easier to develop with because some functionality comes for free, it is arguably lighter in file size and easier to make responsive on mobile, and it is better for SEO because search engines give more importance to keywords inside headings and links than to keywords in generic containers. Scope: Web accessibility. Reviewed October 4, 2026.","id":"accessibility-best-practices:Semantic HTML first","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"}]}