ReadMeFeed / Community knowledge
Real questions. Useful conversations. Find the people who know your stack.
Focus indication conflict in StackBlitz modals When a modal dialog opens in StackBlitz, the interface currently applies both a visible CSS outline to the newly focused element and an ARIA live region announcement for screen‑reader users. The design does not specify which mechanism should take precedence, which can result in duplicate announcements or a missi
Qwik’s lazy resumability means server-rendered HTML can contain focusable elements before their component code loads on the client. For accessibility, this creates uncertainty about whether keyboard users and screen reader users encounter a stable, predictable experience when interacting with or navigating to those elements. Standard ARIA attributes and nati
Phoenix LiveView patches the DOM over a WebSocket connection instead of reloading the page, and patched content is not announced to assistive technology on its own. Documented guidance puts that burden on authors: mark dynamic regions with aria-live , as the generated core_components.ex flash component already does, and reach for phx-hook when declarative bi
Bulma provides modal CSS structure with overlay, background and content, but no JavaScript for behavior. With Bulma v1.0.0 remaining CSS-only, focus management, ARIA labeling and keyboard dismissal must be implemented by the consumer. The goal is to configure a Bulma modal for an accessible user-facing workflow while respecting the CSS-only design philosophy
The goal is to ensure that keyboard focus returns to the element that had focus before a Backbone.js view is removed and replaced, especially when views are nested within each other. Manual focus handling requires developers to store document.activeElement in the view’s remove method and restore it in render , which adds boilerplate and can be missed in erro
Symptom In a Gatsby site, navigating between pages moves keyboard focus to the router's wrapper element rather than to the main content region. For screen reader and keyboard-only users, this means a skip-navigation link that targets <main> behaves inconsistently: after a client-side route change, focus sits on the wrapper, and the next Tab press or sk
Context We are migrating a single-page app from Mithril 1.x to 2.x. The routing API changed: route parameters now arrive via the routed component's attrs instead of m.route.param(), and navigation goes through m.route.set(path). The code migration itself is clear, but we have hit an unresolved design decision around accessibility in the user-facing workflow.
I am building a modal dialog as a Mithril component and trying to make it behave correctly for keyboard and screen-reader users. My understanding is that Mithril renders vnodes to plain HTML without injecting ARIA roles, labels, or live regions, and that the framework ships no focus-trapping or focus-return utilities, so everything must be declared in the vn
I'm designing a search filter that issues hx-get requests and swaps results into a container with hx-target , using hx-indicator for the loading state. The goal is for screen reader and keyboard users to perceive each update as reliably as sighted users do. From the htmx documentation I can see the event lifecycle ( htmx:beforeRequest , htmx:afterSwap ) is h
qwik
phoenix
bulma
gatsby
htmx