Open Accessibility

FAQ.KG

Will this plugin make my site fully WCAG compliant?

This plugin helps improve accessibility and addresses many WCAG criteria, but complete compliance requires a comprehensive approach that includes proper content structure, image alt text, semantic HTML, and more. We recommend using this plugin as part of your accessibility strategy, not as a complete solution.

Where will the accessibility widget appear?

You can choose from four positions: left side, right side, bottom left, or bottom right of the screen. You can also customize the size and appearance of the widget.

Can I place the widget somewhere specific, like my site header?

Yes. Use the [open_accessibility] shortcode in your content, a block, or a template file (e.g. <?php echo do_shortcode('[open_accessibility]'); ?>). By default the panel automatically opens toward the side of the screen with the most room, so a toggle placed in your header opens downward and a toggle near the footer opens upward. You can also force a placement with the direction and align attributes:

[open_accessibility direction="down" align="right"]

direction accepts `auto` (default), `up`, or `down`. `align` accepts `auto` (default), `left` (panel extends to the right of the button), or `right` (panel extends to the left of the button).

Can users hide the widget if they don’t need it?

Yes, there’s a “Hide Accessibility Panel” option in the widget that allows users to hide it. It will remain hidden for 24 hours.

Can I generate an accessibility statement for my website?

Yes, the plugin includes a built-in accessibility statement generator that creates a statement based on your organization details.

Does this plugin slow down my website?

The plugin is designed to be lightweight and only loads what’s necessary. The impact on page load times should be minimal.

Can users save their accessibility preferences?

Yes, all user preferences are saved using local storage in their browser, so settings persist between visits.

Will this plugin work in a multisite environment?

Yes, this plugin is compatible with multisite installations.

Can my theme fine-tune which content gets accessibility adjustments?

Yes. Open Accessibility exposes a shared targeting layer that themes can adjust with PHP filters, HTML attributes, and a small JavaScript API. Typography controls use these targets, and the same resolver also supports links, media, interactive controls, and opt-in layout relief.

Example PHP filters:

add_filter( 'open_accessibility_target_roots', function( $roots ) {
    $roots[] = '.my-theme-article-body';

    return $roots;
} );

add_filter( 'open_accessibility_target_excluded_selectors', function( $selectors ) {
    $selectors[] = '.my-theme-sidebar';
    $selectors[] = '.promo-card';

    return $selectors;
} );

add_filter( 'open_accessibility_layout_relief_selectors', function( $selectors ) {
    $selectors[] = '.my-theme-fixed-story-card';

    return $selectors;
} );

add_filter( 'open_accessibility_target_group_selectors', function( $selectors, $group_name ) {
    if ( 'readable_text' === $group_name ) {
        $selectors[] = '.my-theme-readable-copy';
    }

    return $selectors;
}, 10, 2 );

add_filter( 'open_accessibility_target_config', function( $config ) {
    $config['groups']['interactive'][] = '.my-theme-action';

    return $config;
} );

Use open_accessibility_target_group_selectors to refine a specific target group such as readable_text, headings, links, media, or interactive. If a theme needs complete control, open_accessibility_target_config receives the final full targeting array before it is passed to the frontend. Returning an empty selector array disables that default selector set; for example, empty roots disables the automatic body fallback unless a template opts back in with data-oa-root. Built-in widget exclusions and explicit ignore attributes still apply.

Templates can use data-oa-root, data-oa-target, data-oa-ignore, .open-accessibility-ignore, data-oa-relax-layout, and data-oa-preserve-layout. Use data-oa-root to add content roots, data-oa-target to opt an element into one or more groups, data-oa-ignore or .open-accessibility-ignore to exclude a region, data-oa-relax-layout to opt a container into layout relief, and data-oa-preserve-layout to keep a region out of layout relief.

Is there a frontend JavaScript API?

Yes. The plugin exposes window.OpenAccessibility after the widget initializes:

window.OpenAccessibility.refresh();
window.OpenAccessibility.getState();
window.OpenAccessibility.setState({ textSize: 2 });
window.OpenAccessibility.getTargets('readable_text');
window.OpenAccessibility.debug();

window.OpenAccessibility.debug() returns current state and target diagnostics. Frontend selector diagnostics are available from the console and API when the plugin debug option is enabled, or when a developer enables them in the browser with `localStorage.setItem('openAccessibilityDebug', '1')`.

It also dispatches lifecycle events on document: openAccessibility:ready, openAccessibility:targetsRefreshed, openAccessibility:beforeApply, openAccessibility:afterApply, and openAccessibility:reset.

How do I enable debug logging?

To see debug messages from this plugin, you need to do two things:
1. Enable the “Enable Debugging” option in the plugin’s settings page (under the ‘Accessibility’ menu).
2. Ensure that WordPress’s core debugging constants are enabled in your wp-config.php file. Specifically, WP_DEBUG must be set to true, and WP_DEBUG_LOG must also be set to true. Logs will then appear in the /wp-content/debug.log file.

Frontend selector diagnostics are browser-side diagnostics. Use window.OpenAccessibility.debug() or the browser console for those; they are not written to WordPress debug.log.