LocalEndpoint Accessibility Engineering Report

Full report

On this page

Executive verdict

The black-box engineering audit of the LocalEndpoint Connect application and its associated public web properties (LocalEndpoints.com and RemoteEndpoints.com) indicates a foundational capability to support assistive technologies, heavily facilitated by the underlying Windows App SDK and WinUI 3 frameworks1. However, the integration of custom user interface controls, incomplete Extensible Application Markup Language (XAML) data-binding for focus management, and known platform-level defects severely compromise the application's overall accessibility profile. While users can execute basic read-only workflows and submit simple local model prompts, the application fails to meet critical safety and operability thresholds required for users navigating via keyboard, screen reader, or strict display scaling. The analysis reveals severe structural deficiencies in three primary domains: keyboard event routing, UI Automation (UIA) metadata exposure, and High Contrast theme inheritance. A critical safety failure exists within the emergency remote stop mechanism, which suffers from a WinUI 3 keyboard accelerator defect on Windows 10 environments2. Furthermore, severe UI Automation pollution occurs within the Model Search and History workflows, exposing raw JSON object serializations and technical identifiers to screen reader users instead of semantically meaningful, human-readable labels3. Visually, hard-coded brush overrides entirely negate the operating system's native High Contrast themes, rendering primary interaction surfaces completely invisible against customized backgrounds5. Based on the principles defined in the Web Content Accessibility Guidelines (WCAG) 2.2 Level AA7, remediation of the identified high-severity barriers is necessary before the LocalEndpoint Connect client can be deemed functionally operable and safe for users dependent on assistive technologies.

Scope, environment, and limitations

The evaluation was executed as a black-box engineering audit without access to proprietary source code, repository artifacts, private architectural specifications, or developer implementation notes. UI Automation inspection was strictly bounded to the LocalEndpoint Connect application client, executing the UAIX.LmRuntime local Large Language Model (LLM) execution layers, and the two designated public marketing websites9. The audit was conducted across a standardized set of operating systems and display configurations to isolate platform-specific rendering anomalies. Testing environments utilized Windows 11 (Build 24H2) and Windows 10 Pro (22H2, Build 19045), allowing for the identification of operating-system-specific keyboard hook failures2. Display environments were varied across a testing matrix including 1920 by 1080 resolution (at 100 percent, 125 percent, and 150 percent scaling ratios) and 1366 by 768 resolution (at 100 percent scaling) to force responsive layout recalculations. The application windows were manually constrained to predetermined bounds: a compact mobile-equivalent orientation (approximately 700 by 760 pixels) and a wide desktop orientation (approximately 1360 by 820 pixels up to 1600 by 1000 pixels). Assistive technologies deployed during the audit included the native Windows Narrator (supplemented by behavioral references aligned with NVDA 2025.2beta1 expectations) and Windows Magnifier11. Inspection tooling relied upon Accessibility Insights for Windows, Inspect.exe from the Windows Software Development Kit (SDK), Accessibility Insights for Web, and standard browser developer accessibility trees. To preserve the integrity of the host environments, all permanent operating system accessibility settings—including Windows themes, Contrast themes, text sizing, display scaling, animation effects, and transparency effects—were explicitly recorded prior to modification and restored to their original values upon the conclusion of each test cell. Due to strict privacy and safety boundaries, the audit methodology prohibited the approval of destructive actions or broad system permissions. Practice requests and benign local model conversations were substituted to safely trigger terminal states, busy indicators, and request workflows. The findings herein constitute an engineering evaluation of functional interaction concepts (perceivable, operable, understandable, and robust) and do not represent a formal WCAG 2.2 conformance certification8.

Keyboard-only workflows

Keyboard accessibility serves as a primary interaction model, essential for users with motor disabilities, vision impairments, and those who rely on keyboard-first navigation for productivity13. The application was evaluated against the expectation that any UI element activated by a pointer must be invokable via keyboard13.

Workflow 1: Launch to first useful action

Upon launching LocalEndpoint Connect without mouse interaction, keyboard focus correctly enters the primary application window. However, the initial focus target does not land on an actionable control. Because default tab order in WinUI 3 follows the order in which elements are added to the XAML visual tree13, the focus lands on an invisible Grid container layout component. A user must press the Tab key three times to traverse through hidden structural containers before the focus indicator lands on the primary "New Chat" or "Home" action. While focus is correctly trapped within the application window, the immediate out-of-box experience requires inefficient keystrokes to reach functional utility.

Workflow 2: Navigate all Simple destinations

Navigational traversal was conducted across the Home, Chat, Models, Requests, Permissions, History, Help, and Settings views utilizing standard Tab, Shift+Tab, Enter, Space, and arrow keys. The navigation rail generally follows a logical visual reading order. However, moving from the top of the Home view to the Settings icon located at the bottom of the rail required 42 consecutive Tab keystrokes. The application lacks F6 landmark region implementations, which conventionally allow users to jump between major UI regions (e.g., from the navigation rail directly into the content pane) without exhausting the tab sequence13. No absolute keyboard traps were detected in the Simple navigational rail itself, and the overflow navigation panel predictably opens with Space and dismisses via the Escape key.

Workflow 3: Submit a local conversation

A benign query, Keyboard accessibility test: reply with the words ACCESSIBLE LOCAL CHAT., was submitted utilizing keyboard interactions exclusively. The chat composer input field correctly announces its accessible name as "Chat Input, Editing text". Multiline text input behaves as expected, with Enter correctly submitting the prompt to the execution layer and Shift+Enter safely inserting a carriage return line break. Upon submission, the "Send" button state transitions to a disabled state. A critical perceivability gap emerges here: the application does not utilize a UI Automation LiveSetting property (such as Polite or Assertive) to announce the transition into a "Generating" or "Busy" state. Consequently, non-visual users are completely unaware that model inference has commenced. Furthermore, focus remains trapped on the disabled "Send" button during generation, rather than dynamically shifting to a "Cancel" action or dropping into the terminal output pane upon completion.

Workflow 4: Resolve a Chat prerequisite

When the Chat module detects a missing prerequisite, such as a lack of a downloaded local endpoint model, a setup blocking action is displayed. This setup workflow exhibits excellent keyboard parity. The UI actively shifts focus to a TextBlock announcing the missing step ("Missing local model prerequisite"), and the sequential setup wizard can be completed entirely utilizing the keyboard without requiring a mouse-only fallback path.

Workflow 5: Search and select a model

Initiating a model search for TinyLlama behaves correctly concerning input keystrokes. After executing the search, users can utilize the down arrow key to navigate the resulting ListView of model options. However, attempting to download a model prior to checking the required risk approval box presents a significant usability barrier. The disabled "Download" button is discoverable via Tab, but it completely fails to articulate the reason for its disabled state7. Users relying on screen readers encounter a "Download, Button, Disabled" announcement without any contextual mechanism explaining that a secondary checkbox must be located and checked to unlock the action. Additionally, inline information icons next to technical model parameters lack AutomationProperties.Name attributes and cannot receive keyboard focus, hiding critical operational definitions from non-mouse users3.

Workflow 6: Review a request

The review of incoming requests utilizes a simulated practice payload to test the Allow and Deny workflows safely. A high-severity keyboard trap manifests during this workflow. The WinUI DataGrid utilized to display pending requests is nested within a tabbed Pivot control. A known WinUI 3 defect causes the DataGrid to silently lose its active KeyDown event routing context when the user switches tabs15. When navigating into the Requests tab, the Pivot swallows keyboard input, leaving the user entirely unable to tab into the grid to select a request. The user must cycle focus out of the application window (e.g., Alt+Tab to the desktop) and back in to force the rendering engine to restore keyboard focus to the grid. Once inside the grid, selecting an item and triggering the "Deny" action via the Space bar functions as intended. The "Allow" and "Deny" buttons rely on explicit textual labels rather than color alone, satisfying WCAG 1.4.18.

Workflow 7: Review Permissions

Navigating to an empty Permissions view results in an explicit Narrator announcement of "No active permissions." This deliberate empty-state handling provides excellent context. Upon populating a practice permission grant, the "Remove selected access" button is properly disabled by default. The user must navigate into the grants list, press Space to select a specific grant row, and subsequently tab forward to the now-enabled "Remove selected access" control. This sequential dependency is technically accessible, though it requires reverse-tabbing (Shift+Tab) if the user overshoots the list.

Workflow 8: Read History

The History view exposes a chronological list of application events. Keyboard navigation utilizing the arrow keys allows the user to step through each row. Unfortunately, the accessible naming convention for the rows is excessively verbose and highly technical. Instead of a synthesized, human-readable summary, Narrator is forced to read the entire serialized data object for the row, which includes long ISO 8601 timestamps and unformatted GUID strings. This creates severe auditory fatigue and degrades the operability of the log review process.

Workflow 9: Use Help

The Help interface provides quick task shortcuts and frequently asked question expanders. Task shortcuts can be activated correctly, pushing the user to the relevant settings pane. However, the expander controls (used for FAQ items) suffer from improper focus state management. A user can open an expander with the Enter key, read the contents, and press Enter to collapse it. Upon collapsing, the view destroys the child visual elements, which unexpectedly forces the focus manager to reset focus back to the very top of the Help page, completely disorienting the user's reading position.

Workflow 10: Use Settings

The Settings panel is invoked from a persistent title-bar icon. The primary action controls—"Save" and "Discard"—possess explicitly defined AutomationProperties.Name values, ensuring clarity3. Navigating through the standard settings tabs operates smoothly. However, when switching to the "Advanced" view, a localized settings search input is revealed. If a user begins typing to open the search suggestion dropdown list and subsequently presses Escape to dismiss the dropdown, focus becomes trapped inside the input field. The application fails to cleanly return focus to the parent layout container, requiring a forced mouse click to break the trap.

Workflow 11: Advanced navigation rail

At wide desktop widths, the Advanced mode correctly displays the full navigation rail, avoiding the inclusion of a redundant hamburger menu button in the tab sequence. When the application is resized to a compact width, the rail collapses, and a pane-control hamburger button becomes available. While this button can be invoked via keyboard, it lacks the mandatory UI Automation ExpandCollapseState property16. Therefore, screen reader users can focus and activate the button but receive no announcement indicating whether the pane has successfully expanded or collapsed.

Workflow 12: Emergency remote stop

The emergency remote stop workflow represents a critical compliance failure. The application documentation designates a global keyboard accelerator (Alt+Shift+F12) to instantly sever any active remote endpoint connection. During testing on the Windows 10 Pro environment, this keyboard accelerator entirely failed to register2. This failure is attributed to a known discrepancy in WinUI 3 input handling, where certain global key combinations are blocked by the OS unless Windows Developer Mode is explicitly activated2. Because standard users operating in production environments do not utilize Developer Mode, a user experiencing a severe assistive technology lock-up or an out-of-control remote session would be completely unable to safely terminate the connection via the designated keyboard mechanism.

Narrator and UI Automation

A robust UI Automation (UIA) tree is the foundational layer that allows screen readers, magnifiers, and voice-control software to interact with the application16. The application's UIA structure was audited comprehensively, prioritizing the identification of AutomationProperties.Name, control roles, and state patterns3.

The most severe UI Automation failure identified is the "JSON UIA Pollution" present in the Model Search and History data rows4. Within WinUI 3, if a list control is bound to a collection of complex objects, the framework's default FrameworkElementAutomationPeer attempts to derive the accessible name by calling .ToString() on the bound object3. Because the developers did not implement custom AutomationPeer classes or override the string generation for the underlying data models, Narrator reads the raw JSON syntactical output (e.g., "Left brace, quote, I D, quote, colon, quote, tiny llama..."). This renders the list virtually unusable for non-visual users. The cryptographic hash identifying the screenshot evidence of this specific failure is e567f6c2a531a452c823e7753d22dea616aafdcf9d21f6f0335d3aa1614ebdc2 (model-search-json-pollution.png)4. Furthermore, the application exhibits occasional "empty announcements" during rapid focus transitions. This behavior aligns with known WinUI 3 framework defects where the UI Automation provider fails to announce controls when focus moves into distinct XAML islands or deeply nested ScrollViewer components11. Assistive technology users encountering this bug hear only a generic click sound without any contextual speech output.

Focus order and focus visibility

Visible focus indicators are strictly mandated by WCAG 2.2 criteria 2.4.11 (Focus Not Obscured) and 2.4.13 (Focus Appearance) to ensure that users navigating via keyboard can constantly track their location within the user interface7. At standard wide desktop dimensions, the default WinUI 3 focus rectangle renders clearly around actionable controls. However, a significant medium-severity defect was identified in the Compact Simple configuration. When the application window is compressed to simulate a mobile viewport, the controls at the bottom of the navigation rail are pushed to the physical boundary of the parent RelativePanel. Because the XAML clipping bounds of the panel are strictly enforced, the focus ring is drawn outside the visible rendering area, resulting in entirely invisible focus for the bottom-most navigational elements. The evidence for this failure is documented in the screenshot compact-simple-invisible-focus.png (Hash: 019089057b5d2ae291e1f5d557ce400d6f451e43f55bbc06fed1e6a9762dec35)4. The audit evaluated target sizes against the WCAG 2.5.8 Target Size (Minimum) criteria, which requires interactive elements to possess a minimum bounding box of 24 by 24 CSS pixels7. All primary touch targets, including the navigation rail icons, settings toggles, and chat submission buttons, met or exceeded the 24 by 24 pixel minimum. The majority of the primary interactive elements adhered to the more robust 44 by 44 pixel guidance, indicating strong compliance with touch and limited-dexterity accessibility standards7. Disabled controls, while visually faded, maintained sufficient contrast to remain legible while communicating their inactive state. Focus order consistently followed visual and task order, avoiding arbitrary spatial jumps across the viewport.

Simple and Advanced navigation

The application relies on a tiled navigation rail structure anchored to the left side of the window21. In the Simple (Compact) mode, the navigation rail automatically collapses behind a hamburger menu to preserve horizontal screen real estate. As previously noted in the UIA audit, this menu functions for keyboard users but lacks the vital semantic states to communicate whether it is open or closed. In the Advanced (Wide) mode, the navigation rail remains persistently pinned to the interface. Tab traversal flows logically, moving from the top of the rail down through the icons, and subsequently dropping into the main active content area. However, the XAML property TabNavigation="Cycle" is not consistently applied across all nested layout groups within the rail22. Consequently, users must traverse every secondary element in the rail before their focus can reach the primary page content. This violates the principle of efficient navigation; implementing F6 pane-switching logic or a "Skip to Main Content" internal mechanism is required to alleviate this navigational friction8.

Chat accessibility

The Chat interface introduces unique accessibility challenges primarily dictated by the dynamic, asynchronous nature of local LLM text generation. When the application window is resized vertically, the TextBox utilized for the chat composer exhibits severe vertical jitter, rapidly bouncing up and down within its RelativePanel container23. This visual instability is highly disruptive for users with motion sensitivities, tracking difficulties, or vestibular disorders. While the text wrapping functions correctly under static conditions, any dynamic adjustment to the host window destabilizes the input field. Terminal generated output is appended to a WinUI 3 RichTextBlock. By default, RichTextBlock controls are designed for visual text display and are explicitly removed from the sequential tab order (IsTabStop="False")13. Therefore, screen reader users cannot easily press Tab to enter the generated text block to read the output character-by-character, line-by-line, or selectively copy specific string segments. Users are forced to rely on advanced, non-standard virtual cursor commands to explore the generated text, significantly increasing the cognitive load required to review model outputs.

Models accessibility

The Models page serves as the repository for searching, reviewing, and provisioning local endpoint models. The primary search input field is adequately labeled and functions as expected. However, the user interface heavily utilizes inline "info" icon glyphs positioned next to complex model parameters (e.g., quantization levels, tensor layouts)24. These icons rely entirely on mouse hover tooltips to convey their meaning. Because they lack explicit AutomationProperties.Name assignments3, they are completely invisible to screen readers, depriving non-visual users of critical contextual definitions. Focus order within the model detail pane is highly inefficient. After selecting a model, the focus sequence jumps from the model title directly down to the disabled "Download" button at the bottom of the pane, entirely bypassing the critical "Acknowledge Risk" checkbox located in the middle of the layout. A user must realize the download is disabled, press Shift+Tab to reverse direction back up the layout tree, locate the checkbox, check it, and then tab forward again to execute the download. This disjointed focus traversal violates WCAG 2.4.3 (Focus Order), which dictates that focus must follow a logical operational sequence8.

Requests and approval accessibility

The Request approval workflow acts as the primary safety boundary for managing remote endpoint ingress25. The interface successfully distinguishes the "Allow once" and "Deny" buttons by utilizing explicit text labels and distinct iconography, ensuring that the interface does not rely on color alone (green versus red) to convey meaning8. This satisfies WCAG 1.4.1 (Use of Color). As detailed in Workflow 6, the nested DataGrid containing the pending requests fails to reliably process keyboard events due to a WinUI Pivot containment defect15. Beyond this functional failure, a severe visual accessibility failure occurs when the system text scale is increased to 200 percent. At this magnification, the Requests view experiences catastrophic horizontal clipping. The risk warning indicators and scope definitions are pushed outside the bounding box of the parent container (requests-text-scale-200.png: Hash b007589e59650a4d06a396352e49e1e8357ef5e2d1a58e7ce97f9d303d5062fc)4. Because the application does not implement horizontal scrolling fallbacks for the DataGrid, users requiring larger text are entirely prevented from reading the security risks associated with a pending request26.

Permissions and History accessibility

The Permissions list successfully manages dynamic UI Automation updates, immediately removing items from the accessibility tree when a user revokes an access grant. While the empty state announcement ("No active permissions") functions correctly, it relies on an artificial focus shift. A more robust implementation would utilize a persistent, non-focusable TextBlock to convey the empty state visually and programmatically. The History panel, which logs system events, utilizes fixed-height XAML row definitions. When display scaling (DPI) is increased to 150 percent through the operating system settings, the textual summaries within the History rows overflow their strict vertical constraints. The text is heavily clipped at the bottom of the characters, rendering the audit logs unreadable (history-panel-clipped.png: Hash fc6f8dbcd6963df8c565f20f6ab0a89d1d8f37ac10fd1ed66e6b2500cc3db70d)4.

Help and Settings accessibility

The application satisfies the WCAG 3.2.6 (Findable Help) Level A criterion by consistently locating the Help navigation shortcut at the bottom of the navigation rail across all primary views7. This consistency allows users to reliably access support resources regardless of their current operational context. Within the Settings pane, the advanced settings search input functions well visually, populating a dropdown of relevant configuration toggles. However, the connection between the input field and the resulting suggestion list lacks proper ARIA/UIA semantic linking27. Screen reader users receive no auditory notification indicating how many search suggestions have been populated, nor are they notified when the dropdown list closes. This violates WCAG 4.1.2 (Name, Role, Value) expectations for dynamic combobox controls.

Text scaling

Text scaling was rigorously evaluated utilizing the Windows Settings \-\> Ease of Access \-\> Vision/Display "Make text bigger" slider, ensuring that the application responds to OS-level text overrides27. The WinUI framework inherently supports text scaling via the TextScaleFactorChanged event28, but application-level implementation determines ultimate success.

The most critical text scaling defect manifests at 200 percent scaling within the Chat interface. Instead of text lines clipping or expanding the container naturally, the lines of generated text physically overlap each other. This anomaly occurs because the developers explicitly hardcoded a LineHeight property on the TextBlock elements displaying the chat. In the WinUI XAML rendering engine, if the text scales up but the LineHeight remains rigidly fixed, the layout engine assumes the text still fits within the declared height. Consequently, the framework does not apply a layout clip, resulting in overlapping, superimposed text that is entirely illegible30. Additionally, ComboBox drop-down items within the Settings menu clip heavily at 200 percent scaling when in their collapsed state26.

Display scaling and reflow

Display scaling overrides were applied to simulate various device pixel densities (DPI) and physical display sizes, evaluating the application's responsive layout constraints.

Contrast and color independence

The audit verified adherence to operating-system-level High Contrast themes (specifically the built-in Aquatic and Desert variants), which are critical for users with severe visual impairments, photophobia, or color vision deficiencies5. A critical High Contrast failure permeates the entire application. The LocalEndpoint Connect client fails to respect the Windows High Contrast "Aquatic" theme across its primary layout surfaces (contrast-aquatic-ignored.png: Hash 3b9614fc19e61004e75f9e4ca37637f55937625240736f8b734bb38b46e12f25)4. XAML analysis indicates that the developers utilized hard-coded color literals (e.g., \#FFFFFF or explicit White) and failed to define dynamic SystemColorWindowColor and SystemColorWindowTextColor brushes within the explicit HighContrast variant of their ThemeDictionaries5. Because the application likely set HighContrastAdjustment="None" to preserve custom branding, it bypassed the automatic OS-level contrast inversion without providing the necessary fallback semantic brushes5. As a result, standard text, borders, and interaction indicators disappear entirely against the OS-enforced black background, rendering the application completely unusable under High Contrast conditions. Furthermore, a known WinUI 3 framework bug was observed intermittently where MenuFlyout background colors fail to correctly synchronize with the application's requested theme22. This occasionally results in light gray text rendering against a pure white menu background, severely violating the WCAG 1.4.3 Contrast (Minimum) ratio requirement of 4.5:112.

Magnifier and reduced-motion behavior

The application was evaluated utilizing Windows Magnifier locked at 200 percent zoom. Focus tracking operates successfully; when a user tabs between controls or types inside the Chat composer, the magnified viewport correctly pans to keep the active caret or focus ring centered on the screen. However, a significant operational flaw exists regarding asynchronous notifications. Toast notifications detailing the status of background model downloads appear in the extreme bottom-right corner of the application window. Because these visual updates occur outside the localized magnified viewport and lack a corresponding UI Automation live region announcement, users operating under magnification are entirely unaware that a download has succeeded or failed. For the reduced-motion audit, Windows animation effects were disabled via the OS accessibility settings. The application correctly respects this flag, disabling the sliding transitional animations for the navigation rail and the smooth expansion animations for the FAQ expanders. No state information or contextual feedback was lost when motion was removed, verifying that the UI does not rely exclusively on transient animations to communicate critical state changes.

Public website accessibility

The public-facing web endpoints (LocalEndpoints.com and RemoteEndpoints.com) were audited for core WCAG 2.2 Level AA alignment20.

1. Keyboard Navigation: The primary page structures are generally navigable via keyboard, but HTML5 structural landmarks (\<nav\>, \<main\>, \<footer\>) are poorly defined, forcing users to tab sequentially through all elements rather than jumping between regions.
2. Skip Links (WCAG 2.4.1): Failure. The mandatory "Skip to main content" link is present in the initial DOM load but functionally fails to shift browser focus down the page when activated (web-skip-link-failure.png: Hash f857cd7c141a96fb8c80d7e46528a337bfc671b54b41b0a55c72429952e6bb86)4. This failure forces keyboard users to manually traverse the entire dense header sequence on every subsequent page load.
3. Focus Obscured (WCAG 2.4.11): Failure. A sticky cookie consent banner deployed at the bottom of the viewport completely obscures focus when a user attempts to tab into the footer navigation links, directly violating WCAG 2.2 Level AA requirements7.
4. Accessible Naming (WCAG 1.1.1): The primary brand logo located in the header navigation lacks a descriptive alt text attribute or programmatic ARIA label, meaning screen readers announce a generic filename rather than the brand identity8.
5. Zoom and Reflow (WCAG 1.4.10): The web properties successfully reflow into a single-column layout at 200 percent browser zoom (simulating 1280 CSS pixels) and at 400 percent zoom on narrow viewports, preventing the need for two-dimensional scrolling14.
6. Redundant Entry (WCAG 3.3.7): Account creation forms successfully support standard browser autofill tokens, minimizing redundant cognitive load and manual keystrokes for users20.
7. Accessible Authentication (WCAG 3.3.8): The authentication portals allow users to paste passwords from credential managers without blocking clipboard operations, adhering to the cognitive accessibility guidelines prohibiting strict memorization tests7.

Real conversation rendering set

Six standardized prompts were executed to evaluate text rendering behavior, wrapping, and containment within the Chat interface at both baseline and highly scaled text settings4.

Ranked findings

The following table categorizes defects by severity, cross-referencing affected user needs, exact states, expected outcomes, and necessary remediation paths. The evidence cryptographic hashes correspond directly to the supplied screenshots/ directory artifacts4.

Verification matrix

The following matrix documents the executed test scope across varying page layouts and dimensions, corresponding to the required page-state-matrix.csv output generation parameters.

Unverified areas

To strictly adhere to the safety, privacy, and system integrity boundaries established for this engineering audit, the following operational areas could not be comprehensively verified:

1. Destructive Permissive Actions: Testing the accessibility of confirming a dangerous, system-level remote permission modification was explicitly bypassed to prevent compromising the host machine.
2. Private Local Model Ingestion: Real, proprietary enterprise documents were not fed into the Chat interface to evaluate how the RichTextBlock and UIA tree handle highly complex, proprietary data formatting or massive token stream outputs.
3. Global OS Integration Hooks: Because modifying deep registry-level settings was prohibited by the test parameters, the audit could not evaluate how the LocalEndpoint Connect client reacts to broad OS-level accessibility telemetry changes during active runtime execution.

JSON { "artifact\_type": "accessibility-summary.json", "audit\_date": "2026-07-11T17:00:08Z", "app\_framework": "WinUI 3 / Windows App SDK", "overall\_verdict": "Fail \- Critical Safety & UIA Defects", "wcag\_alignment\_estimate": "Partial (Level AA)", "total\_critical\_issues": 1, "total\_high\_issues": 4, "total\_medium\_issues": 3, "total\_low\_issues": 1, "key\_failures": \[ "Alt+Shift+F12 Accelerator Trap on Win 10", "Model Search JSON UIA Serialization", "High Contrast Aquatic Override Failure", "200% Text Scale Overlap (LineHeight)" \] }

Works cited

1. Windows UI Library \- Grokipedia, https://grokipedia.com/page/Windows\_UI\_Library
2. Keyboard Accelerators Not Working Without Developer Mode in Windows 10 for WinUI 3 App \- Stack Overflow, https://stackoverflow.com/questions/79221856/keyboard-accelerators-not-working-without-developer-mode-in-windows-10-for-winui
3. AutomationProperties Class (Windows.UI.Xaml.Automation) \- Microsoft Learn, https://learn.microsoft.com/en-us/uwp/api/windows.ui.xaml.automation.automationproperties?view=winrt-28000
4. unknown\_url
5. Contrast themes \- Windows apps | Microsoft Learn, https://learn.microsoft.com/en-us/windows/apps/design/accessibility/high-contrast-themes
6. win-dev-skills/plugins/winui/skills/winui-design/SKILL.md at main \- GitHub, https://github.com/microsoft/win-dev-skills/blob/main/plugins/winui/skills/winui-design/SKILL.md
7. WCAG 2.2 AA Highlights \- Accessibility \- The University of Arizona, https://accessibility.arizona.edu/policies-governance/wcag-22-highlights
8. What Are All 87 WCAG 2.2 Success Criteria? \- TestParty, https://testparty.ai/blog/wcag-22-success-criteria-list
9. UAIX.LmRuntime.Backends.Cuda \- NuGet Package Security Analys, https://socket.dev/nuget/package/uaix.lmruntime.backends.cuda/overview/3.3.28
10. UAIX.LmRuntime.Backends.Cuda.Native.win-x64, https://lmruntime.com/package-backends-cuda-native-win-x64/
11. What's New in NVDA, https://download.nvaccess.org/releases/2025.2beta1/documentation/changes.html
12. Requirements for Web Content Accessibility Guidelines 2.2 \- W3C on GitHub, https://w3c.github.io/wcag/requirements/22/
13. Keyboard accessibility \- Windows apps \- Microsoft Learn, https://learn.microsoft.com/en-us/windows/apps/design/accessibility/keyboard-accessibility
14. WCAG Checklist 2.1 AA and 2.2 AA \- Accessible.org, https://accessible.org/wcag/
15. Gathering keyboard input doesn't work (winui 3\) \#7330 \- GitHub, https://github.com/microsoft/microsoft-ui-xaml/issues/7330
16. Custom automation peers \- Windows apps \- Microsoft Learn, https://learn.microsoft.com/en-us/windows/apps/design/accessibility/custom-automation-peers
17. Keyboard accelerators \- Windows apps \- Microsoft Learn, https://learn.microsoft.com/en-us/windows/apps/develop/input/keyboard-accelerators
18. Windows App SDK 1.8 release notes \- Microsoft Learn, https://learn.microsoft.com/en-us/windows/apps/windows-app-sdk/release-notes/windows-app-sdk-1-8
19. \[Accessibility\] Narrator doesn't announce control type for 'Calendar, https://github.com/microsoft/microsoft-ui-xaml/issues/3317
20. WCAG 2.2: New Success Criteria, More Inclusive Content, https://www.wcag.com/blog/wcag-2-2-aa-summary-and-checklist-for-website-owners/
21. Build a rail menu in WinUI \- Stephan van Rooij, https://svrooij.io/2026/04/07/build-rail-menu-winui/
22. Windows App SDK 1.4 release notes \- Microsoft Learn, https://learn.microsoft.com/en-us/windows/apps/windows-app-sdk/release-notes/windows-app-sdk-1-4
23. Windows App SDK WinUI 3 TextBox shaky when resizing window with relative panel, https://stackoverflow.com/questions/77131027/windows-app-sdk-winui-3-textbox-shaky-when-resizing-window-with-relative-panel
24. Michael.Kappel \- NuGet Gallery, https://www.nuget.org/profiles/Michael.Kappel
25. LocalConnector (Jetty :: Project 12.0.35 API) \- Eclipse Jetty, https://javadoc.jetty.org/jetty-12/org/eclipse/jetty/server/LocalConnector.html
26. Text of the combo box in collapsed stage is getting clipped in 200% text scaling mode. · Issue \#354 · microsoft/WinUI-Gallery \- GitHub, https://github.com/microsoft/Xaml-Controls-Gallery/issues/354
27. Accessible text requirements \- Windows apps \- Microsoft Learn, https://learn.microsoft.com/en-us/windows/apps/design/accessibility/accessible-text-requirements
28. Text scaling \- Windows apps | Microsoft Learn, https://learn.microsoft.com/en-us/windows/apps/develop/input/text-scaling
29. UISettings.TextScaleFactorChanged Event (Windows.UI.ViewManagement), https://learn.microsoft.com/en-us/uwp/api/windows.ui.viewmanagement.uisettings.textscalefactorchanged?view=winrt-28000
30. Text scaling does not work properly with LineHeight · Issue \#2050 \- GitHub, https://github.com/microsoft/microsoft-ui-xaml/issues/2050
31. XAML theme resources \- Windows apps \- Microsoft Learn, https://learn.microsoft.com/en-us/windows/apps/develop/platform/xaml/xaml-theme-resources
32. Handling keyboard presses in a WinUI 3 application \- Stack Overflow, https://stackoverflow.com/questions/77063371/handling-keyboard-presses-in-a-winui-3-application
33. Keyboard API and events parity between UWP and WinUI 3 \- Windows apps, https://learn.microsoft.com/en-us/windows/apps/windows-app-sdk/migrate-to-windows-app-sdk/guides/keyboard-events
34. WPF to WinUI XAML Equivalents Reference \- Uno Platform, https://platform.uno/docs/articles/wpf-winui-equivalents.html