# Accessible IoT Dashboard Design with AI-Enhanced Descriptions for Visually Impaired Users
## 3 System Design and Architecture  
### System Overview  
AccessiDashboard is designed as a web-based platform that can be deployed on a typical server or cloud environment to monitor IoT sensor data in real-time. At a high level, the system comprises three layers: (1) IoT data sources (sensors and devices), (2) the server-side application (divided into four services: Data-Ingestion API,Sensors in the field (e.g., temperature sensors, air quality monitors, energy meters) transmit data at regular intervals. The data are sent in a structured format (such as JSON [30]) to the AccessiDashboard server via a RESTful API [31] endpoint. The server, implemented using Laravel, receives the data and forwards them to the back-end ingestion module (Although Laravel was selected for this implementation, other frameworks such as Django (Python) [32] could have been employed as well). In this module, the data is preprocessed and aggregated as needed (for example, smoothing a time series or combining readings from multiple sources). Each incoming sensor reading is saved into the database for persistence and analysis. The data model has a representation for sensors (with metadata like sensor type, units, location) and for sensor readings (timestamped values). A key part of the server-side logic is the AI description generator. When significant new data are accumulated or when a user requests the accessible view of the dashboard, the system compiles a prompt and transmits it to an external LLM service, specifically utilizing the OpenAI API [33] in our implementation. The prompt includes a selection of recent data points, statistical highlights (min, max, average), and context (what the sensor measures, any normal ranges), and asks the LLM to produce a descriptive summary. The returned description is then stored in the database (in a LongDescription table linked to the sensor or visualization) and is made available to the front-end. Caching is used to avoid repetitive calls: if the data has not changed significantly since the last description, the previous description can be reused to avoid unnecessary AI requests. On the client side, the AccessiDashboard front-end is implemented as a single-page web interface that can render in two primary modes: a standard visual dashboard and an accessible textual dashboard. The user can toggle between these modes using a switch in the interface (or a preference can be saved for default). Both modes draw from the same underlying data via the back-end API but present it differently. The standard view shows interactive charts (using a charting library) and minimal textual info, whereas the accessible view emphasizes text and semantic markup. Crucially, the front-end is built with web accessibility best practices in mind. All interactive components (buttons, dropdowns, panels) have proper ARIA labels or roles, focus order is managed logically, and content is organized under headings and regions  
Figure 1: System architecture data flow diagram for AccessiDashboard, illustrating IoT sensors sending data to the server, data processing, and storage in the Laravel back-end (including the AI description generator), and delivery of both visual and textual content to the user’s web browser. for screen reader navigation. The interface is responsive and tested to work with screen readers like NVDA [34] and VoiceOver [35]. Overall, the system architecture allows multiple clients to monitor the same data simultaneously, each choosing a preferred mode of presentation. The use of a robust back-end framework (Laravel) ensures that the solution can be extended or integrated with existing IoT infrastructures (for example, adding authentication for different user roles, or connecting to IoT message queues). The modular nature of the description generation (encapsulated in one service) means the AI component could be improved or replaced without affecting the rest of the system.