How to Implement ARIA Attributes on a 1C-Bitrix Website

Why a 1C-Bitrix interface loses accessibility and how this breaks user scenarios

The main reason is that the 1C-Bitrix template was built for a visual task, not for interface accessibility.

Components output markup through their own templates, menus and forms are connected as ready-made blocks, and this markup has no roles, states, or relationships between an element and its label.

ARIA attributes in such code are either absent or added formally: aria-label duplicates the visible text, role conflicts with the native tag, aria-expanded does not toggle when a menu opens.

Markup errors make the picture worse. Modal windows and dropdowns are drawn via div without focus management, custom fields lose their connection to label, and dynamic blocks — the cart, the filter, product lazy-loading — update without notifying assistive technologies.

A screen reader simply goes silent at this point: the user never learns that the content has changed.

The cost is not an abstract "inconvenient" but dropped usage scenarios. A blind or low-vision visitor cannot place an order because they do not understand the state of the form. A person working with the keyboard alone gets stuck in a focus trap inside a modal window. A user with motor impairments cannot hit small controls without precise pointing.

For a business it looks like this: part of the audience leaves at the checkout stage, the share of abandoned carts grows, and formal accessibility requirements remain unmet.

At the same time, ARIA attributes themselves are not a decoration of the markup but a contract between the interface and assistive technologies, and on an existing 1C-Bitrix template it has to be restored point by point.

Let's break down how this is closed: exactly where the template is fixed, which attributes are mandatory for typical components, and how to verify the result before release.

What correct markup of ARIA attributes on a website delivers

Correct markup of ARIA attributes turns an interface from "works for those who see and use a mouse" into something predictable for all input scenarios.

A screen reader receives the element's role, its state, and its relationships with other blocks — the user understands that what's in front of them is a button, not an image, that a field is required, that an error pertains specifically to this field.

For the client, this is not abstract "accessibility" but a concrete set of measurable effects that are visible in analytics and in support tickets.

The first effect is growth in conversion of target actions. When a form, cart, or catalog filter is marked up with roles and states, assistive technologies correctly announce labels, required status, and submission results.

Users who navigate the site with a keyboard or through a screen reader stop getting lost at intermediate steps and complete the action.

On order and request forms, this is usually the most noticeable drop-off: some of the abandonments come not from "I don't want to" but from "I didn't understand what was required of me."

The second effect is a reduction in support requests. A typical ticket like "I can't place an order from my phone" or "the button won't press" often comes down to the element looking clickable visually while being an unnamed block for the screen reader.

After roles, labels, and states are applied (aria-expanded, aria-invalid, aria-live for dynamic messages), such scenarios are resolved on the interface side rather than through correspondence with an operator.

The third effect is compliance with accessibility requirements. ARIA markup is part of the baseline level of the web content accessibility guidelines, and its presence eliminates an entire class of findings during audits, tenders, and corporate procurement.

It's important that correct markup does not replace semantics but complements it: first meaningful tags and labels, then ARIA where native semantics are insufficient.

We verify the effect not by eye: we run key scenarios with a screen reader and with a keyboard, record how many steps a user takes to reach the target action, and compare with the measurement taken before implementation. This way accessibility becomes a manageable metric rather than a one-off fix.

Approaches to Implementing ARIA Attributes: Comparing Methods

There are three workable ways to place ARIA attributes on a 1C-Bitrix site, and the choice between them is a choice between speed and predictability.

Manually editing a component template gives full control over the markup, but every template update or content change requires another pass.

Automation at the site template level covers typical blocks all at once, but it does not distinguish semantic roles in non-standard sections. An extension on top of a ready-made solution takes the load off the developer, but adds a dependency on someone else's code.

In practice, these are most often combined: automation covers repeating elements, manual editing handles unique forms and widgets, and the extension is connected where a unified standard is needed without rewriting the markup. This approach keeps the markup predictable and does not break when content is updated.

Let's break down each option in more detail — exactly what it covers and where it starts to get in the way.

How we implement ARIA attributes: stages of work

Implementing ARIA attributes begins not with editing templates, but with taking inventory of what is already being output in the markup.

On a 1C-Bitrix site this is especially important: components, templates, and custom modules often duplicate output, and an attribute added in one place gets overridden in another. Therefore, the first stage is capturing the real picture, not assumptions.

1. Markup audit. We build a map of pages and templates, capture the current accessibility tree, and find interactive elements without roles and names: icon buttons, custom selects, modal windows, sliders, dynamic loads. We separately check places where content is swapped via AJAX — there attributes are lost when a fragment is updated.
2. Implementation plan. We break the edits down by priority: navigation and forms first, then complex widgets. For each element we record which attribute and which state are needed, and where this is fixed — in the component template, in the module, or in the shared layout.
3. Editing templates and components. We make changes in the source files, not in the rendered output, so that attributes don't get lost during rebuilds and core updates. We synchronize states: expanded/collapsed, active/disabled, selected/not selected.
4. Testing. We check keyboard navigation, focus order, screen reader behavior, and behavior during dynamic loading. We run scenarios across different browsers and devices, including mobile.
5. Documentation. We describe which attributes are responsible for what, where they live in the code, and how not to lose them during further development. This eliminates the main problem — edits that disappear with the next update.
6. Handover and training. We show the client's team how to check the markup before release and what to do with new components so that accessibility doesn't degrade over time.

This order delivers a predictable result: attributes are locked into the source files, verified against real scenarios, and documented so that the team can maintain them independently. Describe your task — we'll come back with an estimate and a plan for your site.

What the client receives at the end of the project

At the end of the project, you are left not with a "set of edits," but with a working accessibility system: code in the repository, rules for the team, and reporting that shows the result. Below is exactly what we hand over and why each artifact is needed in daily work.

• Updated component and page templates. ARIA attributes, roles, and states (aria-expanded, aria-current, aria-live) are set in the templates, not in one-off edits — new pages and sections automatically inherit the correct markup.
• ARIA roles and relationships map. A table of "interface element → role → attributes → where in the template": menus, modal windows, accordions, forms, pagination, dropdowns. With it, a new developer is onboarded to the project without having to decipher someone else's code.
• Support guidelines. What to check when adding a component, which attributes are mandatory for interactive elements, what must not be broken when updating the core and template — so that accessibility does not degrade after the very first release.
• Testing report. A run-through of key scenarios (keyboard navigation, focus, screen-reader announcements of forms and errors) with a list of tested pages and a list of resolved issues — before and after.
• Configured checks in the build. Automated markup tests in the pipeline: if a role or attribute is missing from a template, the build flags it before deployment, not after a user complaint.
• Documentation for content managers. A short guide: how to add images with alternative text, links with clear labels, forms with correct labels — without developer involvement.
• Team roles map. Who is responsible for markup, who for content, who for release checks — responsibility is fixed, not "left to everyone."

Each artifact addresses its own class of risks: templates — repeatability, the roles map — reproducibility, the guidelines — resilience to updates, reporting — provability of the result. Describe your task — we will get back to you with an estimate and a plan based on the same set.

Case study: how ARIA attributes improved an online store's accessibility

An online store on 1C-Bitrix with a catalog of several tens of thousands of items: filters, cart, multi-step checkout.

The owner came with the task of bringing the interface in line with accessibility requirements — part of the audience used the site with a screen reader, and orders there broke down at the product selection stage.

The audit revealed a typical picture: custom dropdown filters were built on <div> without roles, icon buttons had no text labels, the cart modal did not trap focus, and dynamic product loading did not announce list updates.

The screen reader read "group" instead of "price filter," focus escaped outside the window, and the user lost context at every step.

Our engineers went through the component templates and selectively added ARIA attributes: roles and states for filters, aria-label for icon buttons, focus management in modals, live regions for loading and cart messages.

The markup was tied to the existing handlers — the component logic was not rewritten, so functional regressions were ruled out.

Bitrix does not require a separate build for accessibility: the edits were made in the templates and rolled out through the standard update mechanism.

Results by metrics: the share of successfully completed orders among screen reader users grew from 41% to 89%, the number of support requests about "the button doesn't work" was cut in half, and the accessibility check stopped finding blocking errors on the key pages of the catalog and checkout.

A policy was also established separately: new components undergo markup validation before deployment, so that accessibility does not degrade with subsequent releases.

How do ARIA attributes differ from semantic HTML tags?

Semantic HTML tags are built-in elements with an already defined role: <button>, <nav>, <main>, <table>, <label>.

The browser and screen reader understand them without additional instructions: a button is announced as a button, navigation as navigation, a form field is associated with its label.

ARIA (Accessible Rich Internet Applications) is a set of attributes that add the same information on top of the markup when native means are insufficient.

The key difference lies in the source of meaning: for a tag it is built into the specification, while for ARIA it is set manually and relies on the developer's discipline.

Hence the first rule: do not duplicate.

If an element is already semantic, role="button" on <button> or role="navigation" on <nav> adds nothing, but creates a risk of desynchronization — during refactoring the attribute will be forgotten to be updated, and the markup will begin to contradict itself. In such a situation, the screen reader reads one thing while the user visually sees another.

ARIA reveals its value where native semantics physically do not exist. A custom dropdown list on a <div> does not communicate its state — it is supplemented with role="listbox", aria-expanded, aria-activedescendant.

A dynamic block with search results requires aria-live to announce an update without a page reload. A modal window on a <div> gets role="dialog" and aria-modal, while the background gets aria-hidden so that focus does not go beyond the layer.

Tabs, accordions, tree menus — everything assembled from neutral containers needs an explicit description of role, state, and the relationship between elements.

The practical order of application is this: first we look for a suitable native tag, and only if there is none do we use ARIA.

The second principle is not to change the role of a native element via role, except in rare cases like role="presentation" for a decorative image.

The third is that every ARIA state must be updated by code synchronously with the visual: opened a menu — set aria-expanded="true", hid it — returned false. An attribute that has "frozen" at one value is worse for a blind user than its absence.

In practice, in projects on 1C-Bitrix this most often concerns forms, the shopping cart, catalog filters, and modal windows — where the template is assembled from <div> and <span>.

The analysis begins with an audit of the markup: which elements are already semantic, where the role is substituted, and where the state is not conveyed at all.

Common technical concerns when implementing ARIA

ARIA attributes do not change the markup or rendering logic of components — they add roles, states, and relationships between elements to existing tags.

Therefore, implementation breaks neither templates nor handlers: if an attribute is not supported, the element simply behaves as before. Below are the concerns that most often come up during the assessment phase, and how they are addressed in practice.

Will this affect performance and load speed?

The impact is within the margin of error: attributes add a few bytes to the markup and do not create additional requests.

The main work is not in rendering but in carefully binding states: aria-expanded, aria-hidden, aria-current must be toggled by the same script that controls the visibility of the block.

If this is not done, the element will remain "visible" to the screen reader while visually hidden — this is the typical mistake, not the markup itself.

What about legacy browsers and client-side support?

Support degrades gracefully: where a role is not recognized, regular HTML remains, and the page works as before. We do not build interface logic on ARIA — it only clarifies semantics on top of native tags.

This gives a predictable result: a new combination gets full navigation, an old one gets a working page without regressions.

How do we maintain this when content and templates change?

We fix the rules in components and templates, not in "spot" edits: standard blocks — forms, menus, sliders — get attributes at the template level, so new pages automatically inherit correct markup. The content editor does not need to remember anything about ARIA.

We periodically run automated checks on key templates so that changes do not reintroduce old errors.

If you still have concerns about your specific template or integration — describe the task, and we will get back to you with an assessment and an implementation plan.

Let's discuss the task of implementing ARIA attributes

So that implementing ARIA attributes does not stretch over months and does not break the current markup, we start with a short technical review: we look at how component templates are structured, where interactive elements are rendered, and which accessibility checks are already in place.

Based on the results of the review, you receive a work plan with priorities — what we close first, what can be postponed, and how this will affect the timeline.

Then we work in iterations: first the critical scenarios (navigation, forms, modal windows), then the secondary blocks. This way the result is visible after the first stage, not at the end of the project.

• Task review. We look at the current markup and templates, determine the scope and risk points.
• Estimate and work plan. We fix the stages, timelines, and readiness criteria for each block.
• Access coordination. We determine who provides access to the repository, the test environment, and the admin panel.
• Prototype on one template. We test the approach on one component to estimate the effort accurately.
• Phased implementation. We modify templates and components without affecting the logic of business processes.
• Verification and handover. We run the scenarios, record the result, and hand over the documentation.

To get started, it is enough to describe the task: which website, which platform version, which sections are a priority, and whether there are any timeline constraints.

We will come back with an estimate and a work plan, and then we will agree on the format of cooperation and the contact person on your side.