Accessibility

This website aims to make its articles, guides, tables, and features usable by as many readers as possible, including people with visual, hearing, motor, cognitive, or neurological disabilities. Web accessibility means that a person can perceive, understand, navigate, and interact with content using different devices and assistive technologies.

This document explains the editorial team’s general approach, the standards we use as references, and the measures we aim to apply when designing and updating pages for readers in Argentina. It also explains how to report a barrier related to reading, navigation, or the operation of the contact form.

Accessibility is an ongoing objective, not a claim of perfection. Some pages, images, or external elements may still contain limitations that have not yet been identified. For this reason, we combine technical reviews with reader feedback and prioritize corrections that prevent access to essential information.

Why We Take Accessibility Seriously

Accessibility is not treated as a task that ends after passing an automated review. Content changes, new tables are added, templates are modified, and different devices or assistive technologies appear. As a result, every update may introduce new barriers even when the previous version of a page worked correctly.

For readers in Argentina, this approach must also reflect real access conditions. Some people browse using older mobile phones, unstable mobile networks, or devices shared with family members. Others use screen readers, system magnification, keyboard navigation, voice control, or customized contrast settings.

Our work is organized around three main sources:

International accessibility recommendations.
Automated tests and manual reviews.
Feedback submitted by readers who encounter a specific problem.

An automated tool can identify an image without alternative text, but it cannot always determine whether the description is useful. Similarly, a page may pass technical checks and still be difficult to understand. Human evaluation therefore remains necessary.

Principles That Guide Our Pages

We aim for every publication to follow four basic principles: the information should be perceivable, the interface should be operable, the language should be understandable, and the code should remain reasonably compatible with assistive technologies.

Principle	What it means in practice	Example of application
Perceivable	Information does not depend on a single sense	Alternative text and sufficient contrast
Operable	Features can be used in different ways	Keyboard navigation
Understandable	Content and actions are predictable	Clear headings and direct instructions
Robust	The structure can be interpreted by current technologies	Semantic HTML and accessible labels
Adaptable	The presentation responds to different screen sizes	Mobile design and scalable text
Error-tolerant	Errors can be identified and corrected	Clear messages in the form

These objectives apply equally to a long guide, a legal page, a comparison table, or a contact form.

Standards We Aim to Follow

The website uses the Web Content Accessibility Guidelines, known as WCAG, as a reference. Our working objective is to approach the WCAG 2.1 Level AA criteria without claiming that every page permanently satisfies every requirement.

WCAG 2.0, 2.1, and 2.2 remain published standards. The W3C recommends using the latest version, although WCAG 2.2 remains backward-compatible with the earlier criteria.

Assessments may combine:

Lighthouse for general reviews.
axe DevTools for identifying common problems.
Manual code inspection.
Keyboard-only navigation.
Content magnification.
Contrast checks.
Testing with NVDA.
Testing with VoiceOver.
Mobile testing with TalkBack.
Human review of the content and alternative text.

axe DevTools is designed to integrate automated accessibility testing into web and mobile projects. However, no automated tool can independently assess the entire user experience.

What We Check

Review area	Automated check	Manual review
Text contrast	Yes	Yes
Images without alt text	Yes	Yes
Quality of alternative text	Partially	Yes
Heading order	Yes	Yes
Keyboard navigation	Partially	Yes
Clarity of language	No	Yes
Form labels	Yes	Yes
Screen-reader output	Partially	Yes
Mobile design	Partially	Yes
Table comprehension	Partially	Yes

Tools are used as supporting resources. A positive result should not be interpreted as an absolute guarantee of accessibility.

Reading With Reduced Vision

Visual needs are not the same for every reader. Some people need to enlarge the text slightly, while others use high contrast, a screen magnifier, or a screen reader. The design should avoid making one form of presentation essential for understanding the content.

We aim to keep text readable when zoom is increased, prevent columns from requiring unnecessary horizontal scrolling, and ensure that important information does not depend on color alone.

Informative images should include alternative text that explains their function. This applies especially to:

Charts.
Diagrams.
Interface screenshots.
Infographics.
Icons that communicate an action.
Images containing information that is not repeated in the text.

A decorative image, by contrast, should use an empty alternative attribute so that a screen reader can ignore it. Describing every background or decorative element would create unnecessary noise and slow down navigation.

When an image contains a large amount of information, brief alternative text may be supplemented by an explanation within the article.

Zoom, Contrast, and Color Choices

The design aims to use relative units such as rem and em, allowing text size to respond to browser and system preferences. A person should be able to enlarge the page using zoom functions without losing essential information or access to controls.

On a computer, zoom is usually adjusted through browser options or keyboard combinations such as Ctrl and +. On macOS, Command and + can be used. Mobile devices allow magnification through gestures or system settings.

For contrast, we use the WCAG Level AA minimum as a reference: a ratio of 4.5:1 for normal text and 3:1 for large text.

In addition, we aim to:

Avoid communicating states only through red or green.
Underline or visually distinguish links.
Avoid placing important text over complex backgrounds.
Review buttons in their normal, active, and focused states.
Avoid color combinations that may disappear for people with different types of color-vision deficiency.

Readability depends not only on contrast but also on size, spacing, and typographic clarity.

Screen-Reader Support

The page structure aims to use semantic HTML. This includes one main heading, properly ordered subheadings, genuine lists, tables with headers, and identifiable regions for navigation, main content, and the footer.

Screen readers such as NVDA, JAWS, VoiceOver, and TalkBack use this structure to announce what type of element is currently active. VoiceOver, for example, allows a person to explore and navigate an interface without relying on vision.

We aim to ensure that:

Buttons have understandable names.
Links explain their destination.
Informative images include alternative text.
Form fields have visible labels.
Errors are communicated through text.
The reading order follows the visual order.
Headings are not used only to change the size of the text.
Interactive elements can be identified without exploring the entire screen.

ARIA labels may supplement HTML, but they should not replace semantic elements that already provide the necessary function.

Reading With Cognitive Fatigue

A page may be technically accessible and still be difficult to process. Cognitive fatigue can affect people with dyslexia, ADHD, memory difficulties, stress, temporary illness, or reduced concentration. It may also affect people who read Spanish as a second language.

To reduce this burden, we aim to:

Divide content into short paragraphs.
Use descriptive subheadings.
Maintain one main idea per section.
Avoid unnecessary animation.
Avoid flashing text.
Explain specialized terms.
Maintain a predictable structure.
Present instructions in order.
Use lists when they make processes clearer.
Avoid unnecessarily complex legal wording.

Common industry terms may be retained when necessary, but they should be explained the first time they appear. For example, wagering means a betting requirement, RTP means theoretical return to player, KYC means identity verification, and EDD means enhanced due diligence.

Long publications may begin with an introduction or summary explaining the purpose before presenting each detail. A table of contents may also help readers move directly to the section they need.

Language and Editorial Structure

Possible barrier	Editorial approach
Excessively long paragraphs	Divide them by main idea
Excessive use of English terms	Explain the term in English
Generic headings	Use headings that indicate the content
Ambiguous instructions	State the action, order, and expected result
Overly dense tables	Reduce columns or add an explanation
Unnecessary repetition	Combine related ideas
Unfamiliar abbreviations	Define them at first use
Essential information available only in an image	Repeat it in text

Simplification does not mean removing important information. It means organizing it so that it is easier to find and understand.

Navigating Without a Mouse

Some people cannot use a mouse or touchscreen accurately because of tremors, limited mobility, temporary injuries, or the use of alternative devices. For this reason, the main functions should be available through the keyboard.

Standard navigation should allow users to move forward with Tab, move backward with Shift + Tab, activate controls with Enter or the Space bar, and use the arrow keys when required by the component.

The active element needs a clear visual indicator. We aim not to remove the focus outline through CSS without providing an equally visible alternative. The user should always be able to recognize their current position.

Keyboard reviews aim to confirm that:

The navigation order is logical.
There are no inaccessible elements.
Focus does not become trapped.
Menus can be opened and closed.
The form can be completed.
Links can be activated.
Overlay windows return focus when closed.
Dragging an object is not mandatory.
The main content can be reached without passing through dozens of links.
Actions do not depend solely on precise movements.

When a skip link is used to go directly to the main content, it should become visible when it receives focus.

Accessible Forms

The contact form should be understandable without depending on placeholder text that disappears when a person begins typing. Each field should have a visible label and an instruction where the expected format is not obvious.

When an error occurs, the message should explain what happened and how to correct it. Changing only the border color to red is not enough because some people may not perceive the difference.

Situation	Recommended treatment
Required field left empty	Identify the field by name
Incorrect format	Show a valid example
Message not submitted	Explain whether the user can try again
Character limit	Display it before the limit is reached
Successful confirmation	Show a written message
Spam prevention	Avoid tests that are exclusively visual
Session expired	Preserve entered content where possible

Security mechanisms must also be assessed. A CAPTCHA based only on identifying images may exclude blind users or people with cognitive difficulties.

Audio Choices We Have Made

The website’s content is primarily text-based. This reduces dependence on audio or video for understanding the pages and makes access easier through slow connections or assistive technologies.

We do not aim to include automatically playing audio, pop-up videos with sound, or unexpected effects. Autoplay may interfere with screen readers, reduce concentration, consume mobile data, and expose the user in a shared environment.

When a publication includes audiovisual content in the future, we will aim to provide:

Synchronized captions.
A written transcript.
Pause controls.
Volume controls.
No automatic playback.
Identification of relevant sounds.
Descriptions of essential visual information where necessary.

A video should not be the only way to access important instructions. Wherever possible, the main information will also be provided in writing.

Long audio files should include a transcript that allows readers to search, copy, or review a specific section without listening to the entire recording.

Mobile Access in Argentina

A significant part of the Argentine audience browses using mobile phones and depends on mobile networks whose speed and stability vary according to location, provider, and time of day. Accessibility also means allowing a page to load and remain usable under these conditions.

We aim to reduce unnecessary page weight through:

Optimized images.
Modern formats such as WebP or AVIF where supported.
Lazy loading for images outside the first visible screen.
Defined dimensions to prevent unexpected layout shifts.
Moderate use of external scripts.
Reusable code.
A limited number of fonts.
No automatically playing videos.
A design adapted to small screens.

Touch controls should be large enough and maintain sufficient space between them. As a practical objective, we aim for interactive areas of approximately 44 × 44 pixels where the design allows, especially for buttons, menus, and frequently used elements.

The page should not require extreme precision to close a notice, open a menu, or select an option.

Use With Different Mobile Configurations

A mobile page should remain usable when a person:

Increases the system font size.
Activates high-contrast mode.
Uses TalkBack or VoiceOver.
Rotates the device.
Navigates with one hand.
Disables animations.
Uses a slow connection.
Blocks non-essential scripts.
Accesses the website from a small screen.
Uses voice control.

TalkBack is part of Android’s accessibility toolkit and provides spoken feedback and gesture-based navigation.

We cannot guarantee perfect compatibility with every combination of device, browser, and configuration, but reproducible problems may be added to the review process.

What We Cannot Change in External Content

Articles may include screenshots of MyStake or other operators, extracts from regulatory documents, external charts, embedded videos, or links to third-party websites. The editorial team does not control the code, contrast, forms, or accessibility tools of an external resource.

A casino screenshot may contain:

Small typography.
Low-contrast buttons.
Text embedded in images.
Information that is difficult to enlarge.
Controls that do not meet our criteria.

We cannot redesign the operator’s original interface. However, we can reduce the barrier by adding alternative text, a nearby explanation, or a description of the illustrated action.

When we link to a regulatory PDF, we aim to explain its content and purpose. We cannot always guarantee that the external document is correctly tagged for screen readers.

A third-party link also does not mean that we approve its accessibility practices. Once users leave our domain, the experience becomes the responsibility of the external website.

How We Compensate for External Limitations

When an external element is necessary, we may apply one or more of the following measures:

Describe the image.
Summarize the document.
Explain what the reader will find.
Avoid making a screenshot the only source of information.
State the file format.
Warn that the resource opens another website.
Provide a direct link to the document.
Transcribe important data.
Avoid embeds that block navigation.
Replace external elements when an accessible alternative exists.

The ability to apply these measures depends on usage rights, format, and the information available.

Telling Us About Barriers

If you encounter difficulty reading, navigating, or using a function, you can report it through the website’s contact form. Specific reports help us reproduce the problem and are generally reviewed as a priority.

Where possible, include:

The page URL.
A brief description of the barrier.
The device used.
The browser and its approximate version.
The assistive technology used.
The action you were trying to perform.
The expected result.
What actually happened.

You do not need to send personal information, documents, or casino-account details. A statement such as “the focus disappears when the menu is opened using the keyboard” is more useful than a general message saying that the page is inaccessible.

The form is intended for editorial matters. It cannot be used to report barriers within MyStake or another external platform.

Types of Barriers You Can Report

Problem	Example
Unreadable text	Insufficient contrast
Inaccessible navigation	Menu that does not work with a keyboard
Image without a description	Infographic without alt text
Incorrect reading order	Headings announced in the wrong order
Confusing form	Field without a label
Mobile design issue	Buttons positioned too close together
Unexpected movement	Content that changes position
Cognitive barrier	Instruction that is difficult to understand
Multimedia issue	Video without captions
External document	PDF that cannot be read with a screen reader

The more precise the description, the easier it will be to identify the cause.

Our Update Schedule

Accessibility forms part of the website’s general maintenance. When a template is changed, a feature is added, or navigation is reorganized, we aim to check that the changes have not introduced new barriers.

Reviews may take place:

While a page is being prepared.
Before publishing a major change.
After templates are modified.
When a report is received.
During periodic audits.
When a technical recommendation changes.
After components are updated.

Automated checks may be run more frequently because they can quickly identify basic errors. Manual assessments involving the keyboard, zoom, and screen readers require more time and may be performed in broader cycles, such as after a major redesign or as part of an annual review.

We do not guarantee the same review frequency for every page. Priorities depend on the severity of the problem, the number of users affected, and the importance of the blocked function.

How We Prioritize Corrections

Problems generally receive higher priority when they:

Prevent access to the main content.
Block the form.
Trap keyboard focus.
Hide essential information.
Affect several pages.
Prevent the use of a screen reader.
Cause dangerous or unexpected movement.
Make basic mobile tasks difficult.

Styling adjustments that do not prevent access are also important, but they may be included in a later update.

How Your Feedback Enters the Review Process

Accessibility feedback is not treated only as an isolated message. A specific barrier may reveal a recurring problem in a template, table, or type of image. When this happens, the correction may be extended to several pages.

The editorial team aims to:

Confirm that the message has been understood.
Reproduce the problem.
Assess its impact.
Determine whether it affects other sections.
Apply a reasonable correction.
Test the feature again.
Record the lesson for future content.

Where possible, we may inform the reader who reported the problem about the outcome of the review. However, we do not guarantee an individual response or an exact time frame for each adjustment.

You may also submit a specific technical suggestion through the form, such as an improvement to the focus order, a clearer label, or an alternative format for a table. You do not need to use specialist terminology. Explaining the barrier you encountered and what you needed to do already provides valuable information.