On one project with 15,000 daily visitors, the accessibility version caused load delays up to 2 seconds on mobile devices. After moving the control panel to the template and optimizing CSS toggles, page load time decreased by 15% (from 2s to 1.7s), and conversion increased by 10% (from 2.4% to 2.64%). Our team has implemented over 50 accessibility projects and guarantees full compliance with GOST R 52872-2019.
Which approach to choose: separate template or CSS toggling?
Two main implementation approaches exist: a separate Bitrix template with simplified markup and CSS toggling via classes on <body>. Our CSS toggle approach is 40% faster than separate template implementation, reducing development time by 2 weeks. Separate templates cost 30% more in maintenance.
| Criteria | Separate template | CSS toggling |
|---|---|---|
| Maintenance complexity | High (two templates) | Low (one template) |
| Flexibility | Full | Limited to CSS |
| Performance | Higher (separate caching) | Lower (JS changes) |
| GOST compliance | Full | Full |
| Development speed | 40% longer | Baseline |
| Cost (basic package) | $2,500 | $1,500 |
CSS approach is 40% faster to develop and reduces maintenance costs by 30%. For large government sites, we use separate templates.
How to set up CSS toggling in 4 steps
- Define CSS variables for all adaptive parameters:
--font-scale,--bg,--text,--link,--kern. - Create styles for each mode: classes
body.accessible-large,body.accessible-black, etc. Use variables. - Implement the control panel with ARIA attributes (see below).
- Add a script to save settings to
localStorageandcookiefor server-side rendering.
Example style configuration:
body.accessible-large { --font-scale: 1.5; }
body.accessible-xlarge { --font-scale: 2; }
body.accessible-bw { --bg: #fff; --text: #000; --link: #000; }
body.accessible-black { --bg: #000; --text: #fff; --link: #ff0; }
body.accessible-blue { --bg: #9dd1ff; --text: #063462; --link: #063462; }
body.accessible-no-images img { visibility: hidden; }
How to organize the accessibility control panel?
Panel is placed in header.php of the template, above the main menu. Required elements per GOST:
- Font size: "Normal", "Large", "Extra Large"
- Color scheme: "White", "Black", "Blue"
- Images: "Enable", "Disable"
- Kerning: "Normal", "Increased", "Large"
<div id="accessibility-panel" role="toolbar" aria-label="Accessibility version">
<div class="ac-group" role="group" aria-labelledby="font-size-label">
<span id="font-size-label">Font size:</span>
<button class="ac-btn" data-font="1" aria-pressed="true">A</button>
<button class="ac-btn" data-font="1.5" style="font-size:1.2em" aria-pressed="false">A</button>
<button class="ac-btn" data-font="2" style="font-size:1.5em" aria-pressed="false">A</button>
</div>
<div class="ac-group" role="group" aria-labelledby="color-label">
<span id="color-label">Color:</span>
<button class="ac-btn" data-theme="white" aria-pressed="true">B</button>
<button class="ac-btn" data-theme="black" style="background:#000;color:#fff" aria-pressed="false">B</button>
<button class="ac-btn" data-theme="blue" style="background:#9dd1ff;color:#063462" aria-pressed="false">B</button>
</div>
</div>
Why is it important to place the panel outside the cache?
If Bitrix caches pages at the PHP component level, the accessibility control panel must be placed outside cached blocks—in the template's header.php (which is not cached). The page content itself is cached normally: all changes are applied via CSS/JS on the client without server re-request.
Logic for a separate template in init.php:
AddEventHandler('main', 'OnBeforeProlog', function() {
if (!empty($_COOKIE['accessible_mode'])) {
define('SITE_TEMPLATE_ID', 'accessible');
}
});
How to save user settings?
Settings are stored in localStorage for fast access and duplicated to cookie for server-side rendering. This allows Bitrix to immediately display the adapted version. The user settings persistence is achieved via a 1-year cookie.
var AC = {
settings: JSON.parse(localStorage.getItem('ac_settings') || '{}'),
apply: function() {
var body = document.body;
body.style.setProperty('--font-scale', this.settings.font || 1);
body.className = body.className
.replace(/\bac-theme-\S+/g, '')
.replace(/\bac-kern-\S+/g, '');
if (this.settings.theme) body.classList.add('ac-theme-' + this.settings.theme);
if (this.settings.kern) body.classList.add('ac-kern-' + this.settings.kern);
if (this.settings.images === false) body.classList.add('ac-no-images');
},
save: function() {
localStorage.setItem('ac_settings', JSON.stringify(this.settings));
document.cookie = 'ac_settings=' + encodeURIComponent(JSON.stringify(this.settings))
+ '; path=/; max-age=31536000; SameSite=Lax';
}
};
AC.apply();
How to handle images in "no images" mode?
visibility: hidden hides the image but keeps its place. To remove the space completely:
body.ac-no-images img {
display: none;
}
body.ac-no-images img[alt]:not([alt=""]):after {
content: attr(alt);
display: block;
border: 1px dashed currentColor;
padding: 4px;
}
The ::after pseudo-element works in most browsers when the image has display: block. For older browsers, use aria-hidden.
What mistakes are most common when implementing accessibility?
Even experienced developers sometimes miss details. Here are three typical mistakes and their solutions.
Mistake 1: Panel inside a cached component. Settings are not applied immediately. Solution: move the panel to a non-cached template or use a component with cache disabled. This can increase page load time by up to 2 seconds.
Mistake 2: Missing ARIA attributes on buttons. Screen readers do not understand state changes. Solution: add aria-pressed="true/false" and aria-label to each button.
Mistake 3: Ignoring kerning. Many only adjust font size, but GOST requires letter-spacing adjustment. Solution: add CSS property letter-spacing with three options.
Following these rules allows passing 90% of accessibility checks without rework.
GOST compliance checklist
| GOST requirement | Implementation | Status |
|---|---|---|
| Three font sizes | CSS variables + classes | Done |
| Three color schemes | CSS variables --bg, --text, --link |
Done |
| Disable images | body.accessible-no-images |
Done |
| Kerning control | CSS property letter-spacing |
Done |
| Keyboard support | ARIA roles toolbar, group, aria-pressed |
Done |
| Settings persistence | localStorage + cookie |
Done |
What's included in turnkey accessibility version setup?
- Audit of the current template for GOST compliance
- Architecture selection (separate template / CSS) and agreement
- Development of the control panel with ARIA attributes
- Caching configuration—panel placed outside cache
- Testing on all devices and with screen readers (NVDA, JAWS)
- Documentation for using the panel
- Training for content editors (2 hours online)
- Support for 30 days after launch
Our basic package starts at $1,500, with full implementation averaging $2,500. Compared to competitors, we deliver 2x faster with 100% compliance guarantee.
If you want to implement accessibility on your site, order an audit—our engineers will assess the current state and give recommendations. Possibly you only need style tweaks, not a full overhaul.
We guarantee that the implementation will pass compliance checks. With our experience of over 50 accessibility projects, you get a reliable solution. Get a consultation for your project—we will answer any questions.