# Optional: Notify admin for review if adminReviewEnabled: sendToReviewQueue(sensorID, description)
## 4 Implementation Details  
To demonstrate the practical viability of AccessiDashboard, we developed a functional prototype that realizes the design principles described above. This section describes some key implementation aspects, including how the user interface toggles between modes, how charts and data are annotated with text, and how the integration with an AI API is accomplished. We include illustrative examples from the prototype's code and interface. Figure 3 shows a simplified snippet of the HTML structure used in the dashboard. In this navigation section, two links are provided: one for the \"Accessible Dashboard View\" and one for the \"Standard Chart-based View\". The code uses a -nav role=\"navigation\" aria-label=\"Primary view options\"> to group these controls, and applies the aria-current=\"page\" attribute to the active link to indicate which view is currently selected. This allows screen  
readers to announce the context (that these are view options) and clearly identify the active view, supporting user orientation. A secondary navigation section presents a clear, vertical list of links, each directing the user to a specific data presentation format--\"Bullet Trend List View\", \"Data Grid Table View\", and \"Long-Form Analysis View\". These links are enhanced with descriptive aria-label attributes to ensure their purpose is immediately clear to screen reader users. The entire list is semantically grouped under a visually hidden heading, referenced by aria-labelledby, which provides screen reader users with meaningful context. This approach improves accessibility by using standard HTML elements in a way that supports both keyboard navigation and assistive technologies, without relying on JavaScript or complex interactive widgets. On the server side, each view (bullet list, data grid, analysis) is a separate route that returns the appropriate Blade template. For example, selecting \"Data Grid View\" might navigate to accessible-view-with-datagrid.blade.php which renders the table of recent readings. Laravel's controller will supply that view with the data (e.g., the latest  
Figure 3: Excerpt of the HTML code for AccessiDashboard’s view toggle, showing highlighted semantic markup and ARIA attributes for accessibility. 10 readings from each sensor). In the accessible summary view (the default accessible view), the template shows the most current readings and some summary text. To illustrate the interface outcomes, we include several screenshots of the prototype. Figure 4a displays the standard chart-based IoT dashboard with two line charts on a light background, along with a header containing the AccessiDashboard logo and toggle buttons. Figure 4: (**a**) AccessiDashboard standard chart-based view, showing a typical IoT dashboard with graphs. The screenshot depicts two line charts (Temperature over time in orange, and Humidity over time in blue) on a light background. A header with the AccessiDashboard logo and toggle buttons is visible, with the Standard view active; (**b**) AccessiDashboard accessible summary view, presenting key sensor readings and status in text form. The screenshot shows labeled sections for Latest Environmental Readings (with current Temperature, Humidity, Air Quality Index, Energy Consumption values), Device Status (Online), Location Information (latitude and longitude), and Recent Trends (a paragraph summarizing changes over the past hour). Figure 4b shows the accessible dashboard view (summary mode). Here, instead of graphs, the interface presents information in textual panels. The \"Latest Environmental Readings\" section lists the current values of multiple sensors in a bullet-style list (for example, Temperature: 23.66 \({}^{\circ}\)C, Humidity: 47.32%, Air Quality Index (AQI) [47]: 72 (Moderate), Energy Consumption: 4.16 kWh). These values are accompanied by simple descriptors (like \"Moderate\" for the AQI category).