An accessible dashboard lets people find and use reliable answers, not merely view attractive visualisations. Its gold standard is a coherent decision journey: understandable metrics, usable filters, alternative data representations, appropriate state feedback, trustworthy sources and valid exports. A single technically correct chart is not enough if the whole interactive product excludes the people who need its information.
This article follows the fictional Reading Places Dashboard, where managers need to compare library attendance and waitlists. It distinguishes accessible charts from a complete product with keyboard, screen-reader, mobile, privacy and data-governance responsibilities.
Related eduKate articles cover Accessible Data Visualisation Services for the integrity of individual charts, Digital Accessibility Testing Services for formal evaluation and Accessible Online Form Design Services for complex inputs. Dashboard design coordinates all of these around operational decisions.
The immediate user test
- Can I identify what the number measures, its period and denominator?
- Can I change filters and discover the result without a mouse?
- Can I obtain exact values and explanations without seeing the chart?
- Can I export the authorised data with my selected context?
- Can I tell whether a blank value is zero, missing or deliberately suppressed?
24-chapter interactive reading index
24 chapters, arranged by the user’s journey
Define decisions and readable metrics · chapters 1–5
Interactive controls and equivalent data · chapters 6–11
- Announce meaningful changes without creating noisy output
- Keep keyboard focus and operation predictable
- Use a table when exact values need to be compared
- Explain complex charts without flattening away their meaning
- Make sorting, grouping and drill-downs comprehensible
- Do not communicate status through colour alone
Layouts, context and data quality · chapters 12–17
- Support magnification, text scaling and narrow screens
- Consider cognitive load, plain language and explanations
- Verify missing data, suppressed values and uncertainty
- Tie each KPI to a trusted data source and refresh process
- Keep export and download functionality usable
- Protect privacy when filtering small populations
Assurance, correction and continuous access · chapters 18–24
- Treat third-party chart libraries as dependencies to test
- Combine automated checks with task-based human evaluation
- Test one complete decision rather than isolated widgets
- Verify state changes and error recovery
- Design a feedback and correction route for decisions already made
- Make accessibility part of the release and operations calendar
- The gold standard is a reliable answer reached by more than one route
1. A dashboard is only useful when a reader can make the right decision
A fictional network of community libraries builds the Reading Places Dashboard to monitor attendance, programme waitlists and course registrations. Its home screen has attractive doughnut charts and bright KPI cards. A library manager using a keyboard cannot reach the programme filter. A screen-reader user hears ‘chart, image’ but none of the values. Another manager sees an improvement in attendance without noticing the dashboard changed its date range.
The gold standard of accessible dashboard design is a trustworthy path from data to a useful, independently available decision. Attractive charts alone cannot demonstrate accessibility or accuracy. A real dashboard includes navigation, filters, tables, units, changes of state, explanations, exports and responsible data handling. The Reading Places Dashboard is fictional and its numbers illustrative. This article concentrates on the assembled decision tool, not solely on producing a static accessible chart.
Back to chapter index · Next chapter
2. Define the decision and the person making it
Dashboard requests often begin with ‘show us the important numbers’. That is not sufficiently precise to design an accessible tool. Identify what decisions users will make, their relevant expertise, the information they need and the consequences of misunderstanding the display. The most useful page can be a small number of clear measures rather than an elaborate wall of charts.
The library manager needs to decide which sessions require another instructor, whether waitlists are growing and which locations need outreach. Ask what a useful result looks like and which data source supports it. Include staff who use screen readers, keyboard input, magnification or other tools in discovery rather than assuming every manager navigates visually. An accessible dashboard should not require knowing the designer’s preferred gestures to answer a basic question.
Back to chapter index · Next chapter
3. Choose a comprehensible information hierarchy
Dashboards mix summaries, filters, charts, tables and explanations. The hierarchy should help people find the overview and drill into details without becoming disoriented. Visual positioning alone cannot communicate which information is a heading, which is a label and which is an action. Semantics and predictable navigation make the hierarchy available through assistive technologies.
For the fictional dashboard, start with an identifiable page title, current reporting period and the important measures. Give separate sections for attendance, waitlists and registration outcomes. Use meaningful headings rather than styling every KPI name as a large visual label with no heading relationship. W3C’s headings tutorial explains why semantic structure supports rapid navigation. Readers should be able to find the waitlist section without traversing every decorative tile.
Back to chapter index · Next chapter
4. State periods, units and denominators where numbers appear
A chart can be technically accessible while still misleading if users cannot tell whether a figure counts people, events, registrations or completed sessions. Percentages require understandable denominators and time windows. Relative changes need a baseline. A visual trend without those facts can invite the wrong operational response.
One Reading Places tile claims ‘completion 96%’ but fails to say whether that means forms submitted, registrations confirmed or attendees finishing a course. The manager could allocate resources incorrectly. Put labels, sources and the reporting window close to the number, including in the text alternative or associated explanation. Do not equate an additional decimal place with measurement confidence. Accessibility and statistical honesty are related: users need enough context to interpret the measure.
Back to chapter index · Next chapter
5. Treat filters as functional controls, not decorative chips
Filters may change a dashboard’s entire meaning. Users need to discover available choices, operate them with supported input, know which are active and understand how to clear or reset them. A filter that changes colour without an accessible state can be effectively invisible to screen-reader users. A dropdown requiring precise pointing can exclude keyboard-only users.
The library dashboard has location and time-period selectors. They should have meaningful names, states and predictable behaviour, with a clear route to show all locations again. The W3C ARIA Authoring Practices combobox pattern gives guidance for appropriate implementations. It is not a reason to replace a functioning native select with unnecessary custom scripting. Test the actual control rather than assume a popular component library made it accessible.
Back to chapter index · Next chapter
6. Announce meaningful changes without creating noisy output
Dynamic dashboards update after filters, refreshes or incoming data. Sighted users often notice changing cards visually. Screen-reader users may need an appropriate status message or deliberate navigation path to the new results. But announcing every tick of a frequently changing chart can overwhelm users and make the dashboard unusable.
Define which updates deserve an announcement, which should be reviewable on demand and which need an explicit action to apply. For Reading Places, a message that the result set now includes three branches can be useful when the location filter changes. WCAG Status Messages, criterion 4.1.3 explains programmatic notification of certain changes. Good design makes state understandable without flooding a listener with repeated figures.
Back to chapter index · Next chapter
7. Keep keyboard focus and operation predictable
A dashboard may have many interactive cards, links and menus. The keyboard path should follow meaningful order, show focus visibly and let users return from a drill-down or dialog. A visual popover that closes when the pointer moves away might block someone who navigates by keyboard or switch control.
Walk a complete task without touching the mouse: select a branch, identify its waitlist, open details and return to the comparison. Note where focus becomes trapped, disappears or jumps unexpectedly. WCAG 2.2 includes criteria relevant to keyboard access, focus visibility and obscuration. A dashboard does not meet those user needs merely by putting a generic ‘accessible’ label above an application frame.
Back to chapter index · Next chapter
8. Use a table when exact values need to be compared
Charts excel at showing shape and trends, but many decisions need exact values, especially across branches and programmes. An accessible data table can provide those details in a navigable form. Header cells and data relationships matter; columns separated by visual spacing do not make meaningful tabular structure.
W3C’s tables tutorial recommends appropriate heading associations for rows and columns. The library manager should be able to compare registrations and waitlists at two sites by navigating the same values sighted users see. Avoid massive tables where a filtered and ordered result would serve the task better. Good dashboard design lets people choose a suitable representation rather than treating a decorative chart as the only truth.
Back to chapter index · Next chapter
9. Explain complex charts without flattening away their meaning
Some charts encode multiple series, dates, thresholds or comparisons that cannot be captured in a two-word alternative text. A reader may need a concise overview of the pattern plus an accessible table or structured longer description. The correct equivalent depends on what the chart is meant to help the user decide.
W3C’s complex images tutorial describes a short identification and a detailed alternative that conveys essential values and relationships. If a line chart shows registrations rising in one branch and falling in another, communicate both patterns and their relevant period. An alt label reading ‘attendance graph’ is not enough. The existing Accessible Data Visualisation Services article explores individual chart design; this article coordinates the dashboard around user decisions.
Back to chapter index · Next chapter
10. Make sorting, grouping and drill-downs comprehensible
Interactive tables and charts may sort ascending or descending, group locations and open detailed views. Users need to know which action is available, the current order and what will change after activation. An icon-only arrow can be ambiguous when the table has several sort options.
Use clear control names and feedback such as ‘Sort waitlist, highest first’ where suitable. When a branch is opened in a separate view, preserve a route back to the prior filter context. W3C’s ARIA grid pattern explains focus and keyboard behaviour for genuinely interactive data grids. It is not mandatory for an ordinary static table. Choose native table markup for simple display and a properly implemented interactive pattern only when that complexity offers real value.
Back to chapter index · Next chapter
11. Do not communicate status through colour alone
Green, amber and red are useful visual conventions, but some users cannot distinguish them and screen readers do not automatically communicate their meaning. A status that matters to the decision needs a textual or otherwise equivalent explanation. Contrast and icon shapes should be considered alongside content.
The library dashboard colours sites by waitlist pressure. A manager needs labels such as ‘high waitlist relative to available places’ and the actual counts or thresholds. WCAG Use of Color explains that colour cannot be the only visual way of conveying information. Good practice does not prohibit colour; it keeps the decision available when the colour is unseen or differently interpreted.
Back to chapter index · Next chapter
12. Support magnification, text scaling and narrow screens
Users may enlarge text, zoom the browser or access a dashboard on a phone. Fixed-width charts, sticky navigation and oversized tooltips can create overlaps or force difficult horizontal and vertical scrolling. Some dashboards show a mobile layout that silently removes essential data rather than reflowing it.
Test the Reporting Places journey at relevant zoom and viewport conditions. A phone user must still be able to identify the period, filter locations and reach underlying numbers. WCAG Reflow guidance addresses relevant circumstances and exceptions. A responsive design is not one that looks tidy in a device screenshot while omitting a needed table or preventing access to its last column.
Back to chapter index · Next chapter
13. Consider cognitive load, plain language and explanations
A dashboard can place large amounts of information on one screen and assume experts will know which metric is important. Unclear abbreviations, shifting layouts and unexplained statistical terms can exclude people with less domain knowledge or different cognitive needs. Labels should tell a user what an outcome means and where its definition can be found.
For the fictional library, ‘CR-7d delta’ is less useful than ‘Change in completed registrations over seven days’ with a clear definition. Users should be able to get additional context without leaving the task and losing active filters. Avoid explanations that sound simple but erase valid exceptions, such as counting withdrawn registrations. The goal is comprehensible decisions, not merely the lowest possible reading-age score.
Back to chapter index · Next chapter
14. Verify missing data, suppressed values and uncertainty
Blank cells, zeroes, withheld values and numbers not yet reported mean different things. A visual chart may interpolate or omit points automatically; readers should not be led to conclude that missing information is an actual zero. Data suppression for privacy must be explained appropriately.
Suppose one branch has not submitted its previous month’s attendance. A trend should not silently draw a zero that makes the branch appear to have collapsed. Use a clear ‘not reported’ state and accessible description, and state whether totals exclude that site. Define refresh dates and meaningful caveats. A dashboard that looks polished but conceals gaps may drive unfair decisions even when every keyboard control technically works.
Back to chapter index · Next chapter
15. Tie each KPI to a trusted data source and refresh process
An accessible interface cannot repair a misdefined metric or a broken import. The team needs data owners, calculation definitions, refresh frequencies and methods to reconcile known disagreements. When source rules change, both visual and nonvisual presentation must reflect the new meaning.
Reading Places may have registrations in one system and actual attendance in another. A ‘participation’ tile that combines them without explanation misleads decision-makers. Record the actual source and transformation owner. Make the last updated date visible and programmatically available, and communicate significant known delays. Data governance belongs to the dashboard promise, not just to engineers working behind the application.
Back to chapter index · Next chapter
16. Keep export and download functionality usable
Managers may need to share a report, download underlying rows or provide a meeting pack. A visual screenshot can be insufficient for detailed analysis or screen-reader access. Exports should preserve meaningful headers, correct units, selected filters and the reporting period.
Provide practical alternatives such as an accessible HTML table, carefully structured downloadable data or an appropriate tagged document where required. Confirm that the exported values match what the user selected, rather than always returning a global unfiltered dataset. If the exported file is sensitive, use appropriate access control and avoid placing private participant data in an unsecured attachment. A useful dashboard remains useful when information leaves the screen.
Back to chapter index · Next chapter
17. Protect privacy when filtering small populations
A school or library dashboard may contain information about children, attendance, household needs or staff. Small subgroup filters can reveal information not obvious in broad totals. Accessibility should not become a reason to expose sensitive identities; equivalent information can be provided with appropriate aggregation and legal safeguards.
Decide which users may view the dashboard and which detailed rows they are authorised to export. Where counts are suppressed, explain the withheld state without publishing the sensitive number through screen-reader-only markup. The same access and privacy policy should apply across visual charts, tables and downloaded reports. In the fictional case, the manager’s need to allocate instructors does not automatically justify access to identifiable personal histories.
Back to chapter index · Next chapter
18. Treat third-party chart libraries as dependencies to test
A dashboard built on a commercial analytics platform may include charts and filters that the product team cannot easily edit. A vendor’s marketing claim about accessibility does not establish that every chart instance and custom interaction works in the assembled interface.
Request evidence and test actual tasks rather than relying on the chart library’s general documentation. A filter embedded from another provider may trap focus or fail to announce its selected state. The product owner should define contract responsibilities and a practical alternative if a defect cannot be fixed immediately. A third-party boundary may explain the cause, but it does not make the user’s blocked decision disappear.
Back to chapter index · Next chapter
19. Combine automated checks with task-based human evaluation
Automated scanners can identify some missing names, markup or contrast issues. They cannot fully determine whether the current measure is correct, whether a trend explanation makes sense or whether a screen-reader user can complete a complex comparison. Accessibility evaluation must include relevant manual checks.
WCAG-EM 2.0, published in July 2026, describes a five-step methodology for evaluating digital products, including apps. A dashboard audit should scope core user journeys, explore its dynamic states, select representative samples, evaluate with meaningful evidence and report limitations. Include users who rely on relevant access methods where practical. Passing an automated score is a beginning, not a conclusion.
Back to chapter index · Next chapter
20. Test one complete decision rather than isolated widgets
A dashboard can have separately accessible controls and still fail as a complete task when the selection does not persist, the chart has no equivalent values or navigation loses context. Task-based review should start with a real management question and follow the user’s steps until they can act on the answer.
For Reading Places, ask a keyboard or screen-reader user which branch has the largest current waitlist relative to available places, then have them reach the supporting rows and explain the calculation. Observe without coaching. If they can locate numbers but cannot tell which filters are active, the experience is still inadequate. Record the precise cause and do not treat one participant as statistically representative of every disability group.
Back to chapter index · Next chapter
21. Verify state changes and error recovery
Data feeds can fail, filters may return no results and sessions may expire. Accessible error messages should distinguish no matching data from a broken service and give the user a practical recovery route. A blank chart should not silently suggest that all values are zero.
Use an understandable live status where appropriate, preserve the user’s context through retry and avoid forcing the person to rebuild every selection after a minor error. Test a legitimate empty result, a temporarily unavailable dataset and an expired session separately. WCAG criteria for status and forms may apply depending on interaction. The dashboard must explain what happened to the information rather than display an unlabelled spinning symbol indefinitely.
Back to chapter index · Next chapter
22. Design a feedback and correction route for decisions already made
Readers may spot a mislabeled metric, inaccessible control or source inconsistency after a report influenced staffing. The dashboard owner needs a way to receive, investigate and correct such reports while preserving the affected dates and versions. A silent correction can leave previous exports in circulation without explanation.
Record what was changed, the underlying source and the affected reports or users when the consequence warrants it. For a wrong waitlist calculation, the organisation may need a correction notice and revised downloadable file, not just a fixed chart. Distinguish a design defect from a statistical error and route each to the appropriate accountable professional. Accurate recovery reinforces trust more than an unrealistic promise that the dashboard will never contain a defect.
Back to chapter index · Next chapter
23. Make accessibility part of the release and operations calendar
Dashboards evolve as new metrics, filters and data vendors are added. A successful one-off audit is not a permanent guarantee. Changes to shared components, charts or export logic can reintroduce earlier barriers, particularly where custom interactions are involved.
Give product teams reusable accessible design patterns, automated checks for detectable defects, manual scenarios for essential tasks and a release owner. Record supported browser and assistive-technology configurations and known limitations. A new time filter should be tested for keyboard, state announcement and correct calculations before reaching managers. The long-term service is the ability to keep answering useful questions after developers move on.
Back to chapter index · Next chapter
24. The gold standard is a reliable answer reached by more than one route
The fictional library dashboard now allows users to select a branch through accessible controls, understand the reporting period, read underlying values in a structured table and retrieve an appropriately scoped export. The trend chart has an equivalent summary, filter changes are discoverable and missing information is not misrepresented as zero.
Accessible dashboard design earns its gold standard when people can obtain trustworthy answers through the interaction methods they use. It is not a catalogue of compliant widgets or a chart gallery. It joins usable navigation, reliable data semantics, privacy, transparent uncertainty and actionable decisions in one maintained product.
Worked example: choosing where to add instructor capacity
The example is fictional. The manager’s real task is to compare branch waitlists relative to available places, not merely admire an attendance chart. Each stage should provide equivalent meaning across access modes.
| Decision step | What initially failed | Meaningful evidence |
|---|---|---|
| Select current month | Colour-only filter state | Keyboard control and announced selected period |
| Compare sites | Unlabelled image of chart | Accessible summary and correct branch-value table |
| Understand waitlist rate | Percentage without denominator | Clear numerator, places and reporting window |
| Identify missing report | Blank plotted as zero | Missing-data status and appropriate exclusion note |
| Export decision pack | Global totals ignore chosen filters | Correct authorised, structured dataset |
Dashboard acceptance and ownership matrix
This matrix separates data authority, interactive implementation and accessibility verification, which are sometimes incorrectly assigned to a single visual designer.
| Responsibility | Owner | Proof |
|---|---|---|
| Metrics and calculations | Domain/data owner | Definitions, source, units, period and limitations |
| Controls and navigation | UX/development lead | Complete keyboard and assistive journey |
| Charts and tables | Information designer | Equivalent values, trends and accessible structure |
| Access and exports | Service/privacy owner | Authorised, secure and correctly scoped results |
| Retest and publication | Quality/release owner | Recorded scenarios and corrected live build |
Dashboard release checklist
- Define important reader decisions and the relevant data sources.
- Present clear periods, units, denominators and uncertainty.
- Ensure filters, sorting, drill-downs and reset work through supported input.
- Provide structured tables and appropriate equivalents for complex charts.
- Do not use colour alone to convey status or suppress sensitive data only visually.
- Preserve the selected context during refresh, error recovery and export.
- Test narrow screens, zoom, screen reader and keyboard journeys.
- Retest after shared component, data schema and platform changes.
- Keep factual corrections, limitations and support channels understandable.
Frequently asked questions
These questions clarify the separation between accessible visualisations, interactive widgets, reliable data and meaningful dashboard outcomes.
1. Is providing a data table enough to make a dashboard accessible?
A properly structured table is often essential when people need exact data, but the dashboard may still fail if filters cannot be used, states are hidden or totals are wrong. The accessible route must connect the intended decision, controls, data and relevant explanations. Test a complete task from selecting a period to reaching the correct figure. The table is an important alternative for many charts, not a universal substitute for accessible interaction.
2. Should every chart have a long alternative text?
Not necessarily. A short description should identify the chart, while complex images may need detailed explanation of relevant patterns and values. If adjacent text and an accessible table already provide the equivalent information, avoid needless duplication. The purpose of the chart and the user’s task determine what is necessary. A generic label such as ‘bar chart showing results’ is rarely sufficient when the chart supports a meaningful operational decision.
3. How should filters work with a screen reader?
Users need names, available choices, current selection and appropriate feedback after a change. Native controls often provide useful behaviour when implemented properly; custom comboboxes and data grids need deliberate keyboard and focus management. Announce meaningful result changes without flooding users with continuous messages. Test the specific browser and assistive-technology combinations in scope, as well as the entire task after choosing a filter.
4. Are ARIA grids always better than HTML tables?
No. A static data table is often best presented with native HTML table markup, including appropriate row and column headers. ARIA grid patterns are for interactive composite widgets and require specific keyboard and focus behaviour. Adding grid roles to an ordinary table can make navigation needlessly complex or break normal assistive-technology expectations. Choose the simplest correct structure for the interaction actually required.
5. Can a beautiful chart still be factually wrong?
Yes. A wrong denominator, mismatched time window, incomplete source feed or hidden missing-data treatment can produce a convincing visual pattern with an unsupported conclusion. Accessibility must include meaningful numeric context. State units, periods, calculations and uncertainty as needed. A chart with an excellent text alternative to the wrong underlying number remains untrustworthy, so data validation and content review are part of design acceptance.
6. How should missing values be represented?
Distinguish a genuine zero, no report, suppressed sensitive value, not applicable result and unavailable source. These are different states with different decision implications. The visual display, accessible table, export and explanatory text should agree. Do not draw a missing period as zero and allow managers to infer a collapse. Where small counts are suppressed for privacy, the accessible representation must not accidentally disclose the hidden value.
7. How can dashboard designers handle colour-based status?
Use colour as a supporting signal, with a meaningful text label, symbol or other perceivable distinction that conveys the same status. Explain the threshold or rule producing the status and show relevant underlying data where appropriate. A green/red scheme alone can exclude colour-blind users and screen-reader users. The solution need not eliminate useful visual design; it ensures status survives without reliance on hue.
8. Does WCAG 2.2 guarantee the dashboard’s statistical correctness?
No. WCAG concerns defined accessibility criteria for web content. It does not validate the underlying data model or management decision. A sound project checks both: WCAG-related interface and content access, plus data provenance, units, calculations, source consistency and meaningful explanations. A formally accessible but incorrect dashboard can still harm decisions. Quality assurance needs technical accessibility expertise and qualified data/domain review.
9. What should a keyboard-only acceptance task include?
Have the participant navigate to the dashboard, identify the period, change a filter, inspect a relevant number or table, open detailed information and return without using a pointer. Watch focus visibility and order, popovers, keyboard traps and whether the filter state remains understandable. A passing Tab sequence on the homepage is not sufficient. Document exact environment, actions, observed issues and retest results.
10. How can a team verify downloadable reports?
Check that the export corresponds to selected filters and version, preserves units and headers, and respects access permissions. Use a format that recipients can navigate with appropriate tools. Verify that the file opens and that the values agree with the dashboard’s authorised data. A screenshot-only export can obscure exact data and make navigation difficult. For sensitive rows, apply the same privacy and authorisation rules as the onscreen interface.
11. Do dashboards need testing on small screens?
Test the actual product’s supported responsive use, including zoom, text scaling, touch controls and important table columns. Reflow can change navigation and hide filters that are available on desktop. Some complex data visualisations may have relevant WCAG exceptions, so apply normative requirements rather than inventing a universal layout rule. The practical question is whether the user’s essential decision can still be completed through the supported device route.
12. How should a dashboard update a screen-reader user?
Announce consequential state changes appropriately, such as a completed filter action or an error needing attention, and make updated results easy to find. Constant announcement of high-frequency incoming data can be unusable, so provide intentional review or refresh controls where appropriate. WCAG Status Messages gives relevant requirements in its scope. Test meaningful comprehension and keyboard context rather than adding ARIA live regions indiscriminately.
13. Can a vendor accessibility certificate settle an embedded chart issue?
No general vendor declaration proves that a particular embedded component works inside your dashboard’s actual interaction and browser environment. Review the vendor’s scope and evidence, then test the assembled journey. Contractual responsibility for fixing the component should be clear. If an essential decision remains blocked, the product owner should evaluate an appropriate, secure alternative rather than dismiss the issue because the component came from another provider.
14. How often should a dashboard be retested?
Retest meaningful interactions after changes to filters, grids, reports, data schema, shared widgets and third-party integrations. Use automated checks for detectible regressions and periodic manual and user-task review for more complex issues. There is no one frequency that suits every product. Connect testing to the release cadence and to the consequences of inaccessible decisions. Keep previous known fixes as regression scenarios so a new chart does not recreate an old barrier.
Verified primary references and related eduKate guidance
- W3C WCAG 2.2
- W3C Complex Image and Chart Alternatives
- W3C Tables Tutorial
- W3C ARIA APG Grid Pattern
- W3C ARIA APG Combobox Pattern
- W3C WCAG Status Messages
- W3C WCAG-EM 2.0 July 2026
- W3C User Evaluation Guidance
- eduKate — Accessible Data Visualisation
- eduKate — Digital Accessibility Testing
- eduKate — Accessible Online Form Design
- Gold Standard Sector and Services Directory
Scope note, October 2026: WCAG 2.2 provides accessibility success criteria; WAI-ARIA Authoring Practices are implementation guidance for appropriate interactive patterns, not a mandate to use custom ARIA everywhere. WCAG-EM 2.0 is a Group Note supporting evaluation, not W3C product certification. A usable dashboard must also have valid underlying data and appropriate privacy controls; no accessibility standard certifies every statistic displayed.