8 posts tagged with "Accessibility"

The question: At phone width the skin had no link out to the site — stock wp-admin puts a house in the toolbar whose menu holds Visit Site, and the skin hides that item. Should the skin grow its own front-end link in the off-canvas panel, or give core's item back?

The question: While sweeping the admin for light surfaces in dark mode, four separate panels came up as "still white — fix it?": the classic editor's writing area, the Box Style / Table Style / Border Hover Animation picker swatches, and the Box Shadow preview. Are those bugs, or are they meant to stay light?

The question: Walking the DOM from <body> down to the first page-builder <section> shows a stack of wrappers — #page.site → #content.site-content → main#main.site-main → article.fw-col-12 → .entry-content → the plugin's .fw-page-builder-content → section. For a full-width, all-builder page that's a lot of nesting. The obvious first cut is the outermost one: drop #page and move its .site layout (the flex column, min-height:100vh) onto <body> itself. Should we?

The question: The Flexbox options modal feels disorganized — a single element renders a Section band, a Flex row, a Grid, or a plain Block depending on an HTML Tag and a Display select, and the one modal shows every option for every kind. Since nobody switches a root section to a div, or a flex to a grid, after dropping it — should we split the Flexbox into separate shortcodes / item types per kind so each has its own clean, tailored option set?

The question: How should the theme handle responsive typography long-term — keep stepping sizes at a breakpoint, add per-device controls to every field, or move to a fluid type system? And what has to be true for a fluid system to not fail accessibility?

The question: A button set stores the same value a radio stores — one key from a fixed set of choices. Everything else is presentation. So should it be a new option type at all, or just 'display' => 'buttons' on radio?

The question: Builder pages started rendering the theme's page title as an H1 bar above the built content (so "every page has exactly one H1"). Was that a good default — or should the theme title simply be disabled whenever the Page Builder is used, leaving the per-page "Hide the page title" checkbox to classic-editor pages only?

The question: An AI browsing agent reads a page two ways — through the accessibility tree (roles, names, states) and through the server-rendered HTML (text, links, and machine-readable structured data). Should UnysonPlus invest in being "agent-ready" across both channels? And does that investment include building a WebMCP integration (page-exposed tools an in-browser agent can call) now?