Accessibility Notes

This website aims to make its materials accessible to as many readers as possible, including people with visual, hearing, motor, or cognitive disabilities and difficulties. The objective is to ensure that articles, tables, forms, links, and images can be understood and used across different devices and assistive technologies.

These notes describe the principles that guide the website’s design, writing, and technical review. They also explain the limitations that may affect screenshots, external documents, embedded content, or tools managed by third parties.

Accessibility is not considered a task that can be completed once and then forgotten. Browsers change, new devices appear, standards are updated, and readers may encounter barriers that automated checks do not detect.

For this reason, our approach combines gradual improvements, editorial review, technical testing, and feedback submitted through the website’s contact form. The aim is to reduce barriers without claiming that every page is perfect or fully compatible with every possible combination of browser and assistive technology.

Why Accessibility Matters Here

Accessibility is important for any informational website, but it becomes especially significant when the content includes bonus rules, wagering requirements, payments, KYC verification, withdrawal conditions, and technical terminology.

A sentence that is difficult to read or a poorly structured table may cause a reader to misunderstand a financial condition. Accessibility therefore involves more than adding alternative text to images. It also requires organizing information, using understandable language, and presenting warnings clearly.

In Argentina, some people access the internet through unstable mobile connections, older smartphones, or devices shared with family members. Others rely on screen readers, magnification tools, keyboard navigation, or high-contrast settings.

Improvements designed for these situations also benefit people who:

Read after a long working day.
Use their phone in bright sunlight.
Have a temporary injury.
Are learning casino terminology.
Browse using a slow connection.
Prefer brief and structured explanations.

Accessibility therefore improves the general user experience rather than serving only one specific group.

The Technical Benchmark We Aim For

The website uses the Web Content Accessibility Guidelines, known as WCAG, version 2.1 at Level AA, as its main reference.

WCAG consists of guidelines developed by the World Wide Web Consortium to improve the perceivability, operability, understandability, and technical robustness of web content. Level AA includes criteria widely used as a benchmark for websites and applications.

Our intention is to move progressively toward this level, but this statement should not be interpreted as an independent certification or a promise of complete compliance across every page.

Reviews may combine:

Automated checks using Lighthouse.
Analysis using axe DevTools or equivalent tools.
Manual review of contrast and structure.
Complete navigation using only a keyboard.
Testing with screen readers such as NVDA or VoiceOver.
Checks on mobile devices.
Content reviews at different zoom levels.

Automated tools can identify certain errors, but they do not replace human assessment. A button may pass a technical test and still have a label that is difficult to understand.

Area assessed	Accessibility objective	Testing method
Structure	Logical hierarchy of headings and page regions	HTML and screen-reader review
Contrast	Sufficient readability between text and background	Contrast-checking tools
Keyboard	Access without using a mouse	Tab, Shift + Tab, Enter, and arrow keys
Images	Text alternatives where images provide information	Manual alt-text review
Forms	Clear labels and understandable instructions	Keyboard and screen-reader testing
Zoom	Enlarged reading without losing essential information	Testing at up to 200%
Mobile	Usable buttons and responsive content	Testing at different screen widths
Language	Clear explanations of technical terms	Editorial review

If You Have Difficulty Seeing the Content

The design and editorial structure aim to accommodate different levels of visual ability, from mildly reduced vision to permanent use of a screen reader.

The main areas of focus are text size, contrast, heading hierarchy, link identification, and alternatives for relevant images.

We do not rely on color alone to communicate important information. For example, a warning should not be identified only by a red background. It should also include a heading, an understandable icon, or a written indication.

We also aim to avoid images that contain essential information without an equivalent explanation in the article text.

Specific features may vary depending on the page, browser, and device. When a setting does not work correctly, readers can report it through the contact form so that the editorial team can assess a possible solution.

Making the Text Larger

We aim to use relative units such as rem and em so that text size responds to browser and operating-system settings.

In most desktop browsers, zoom can be adjusted using:

Ctrl and + to zoom in.
Ctrl and − to zoom out.
Ctrl and 0 to return to the default size.
Command instead of Ctrl on many Apple devices.

You may also use the text-size, screen-zoom, or accessibility options available in Android, iOS, Windows, and macOS.

Our objective is for essential content to remain readable and functional when enlarged to 200%. This value is part of the WCAG 2.1 criteria for resizing text without losing content or functionality.

Additional vertical scrolling may appear, but paragraphs, buttons, and essential controls should not become hidden.

Color and Palette Choices

Color selection aims to maintain sufficient contrast between text and its background.

As a reference, WCAG 2.1 Level AA establishes a minimum contrast ratio of 4.5:1 for standard text and 3:1 for large text, subject to certain exceptions.

Color should not be the only way to distinguish:

Links.
Errors.
Notices.
Button states.
Required fields.
Table results.

Links within text may also use underlining, changes in font weight, or other visual indicators. This helps people with color-vision deficiencies and those using screens in poor viewing conditions.

We also aim for the website to respond reasonably to system settings such as high-contrast mode. However, some customized combinations may alter colors, icons, or borders in ways that we cannot fully control.

The page structure aims to use semantic HTML so that screen readers can correctly interpret the order of the content.

This includes:

One main h1 heading.
Properly ordered subheadings.
Lists created using genuine list elements.
Tables with identifiable headers.
Navigation and content regions.
Buttons with understandable names.
Form fields with labels.
Alternative text for informative images.

Testing may be performed with tools such as NVDA, VoiceOver, or TalkBack. JAWS is also widely used, although we cannot guarantee identical results across every version, browser, and operating system.

Purely decorative images may use empty alternative text to prevent unnecessary interruptions. Informative images should include a description that communicates their purpose rather than merely listing visible objects.

If Focus or Reading Speed Is Difficult

Reading difficulties are not always related to vision. Some people need more time to process information, maintain concentration, or remember what was explained in an earlier section.

For this reason, we aim to avoid excessively long paragraphs, use descriptive headings, and separate important conditions into tables or lists.

These choices may help readers with dyslexia, ADHD, cognitive fatigue, or memory difficulties. They also benefit anyone reading a guide on a mobile phone, while travelling, or after a long working day.

Where the website configuration allows, we avoid:

Moving backgrounds.
Flashing text.
Unnecessary animations.
Windows that repeatedly interrupt the user.
Automatically changing content.
Excessively long instructions.
Promotional language that hides important conditions.

An accessible page should not require readers to remember information from several different sections in order to understand a basic warning.

How We Structure Pages

Long articles are divided into sections identified by headings that indicate what each part contains.

Where useful, we may include:

Introductions summarizing the main idea.
Comparison tables.
Step-by-step lists.
Separate warnings.
Summaries of conditions.
Frequently asked questions.
Practical conclusions.

This structure allows readers to locate information without necessarily reading the entire page from beginning to end.

For screen-reader users, a correct heading hierarchy makes it easier to move between sections. We therefore aim not to select headings based only on their visual size. Each heading level should represent a logical relationship with the content.

Not every page requires an FAQ section or a separate summary. The structure is adapted to the topic, but it should remain predictable and avoid unjustified jumps between heading levels.

Language We Aim to Keep Simple

Online casinos use many English terms. Words such as RTP, wagering, cash out, cashback, KYC, or EDD may appear even in interfaces translated into Spanish.

When a technical term is necessary, we aim to explain it the first time it appears. For example, it is not enough to state that a bonus has a wagering requirement. It should also be explained that this is the number of times a balance must be wagered before the withdrawal conditions are met.

We aim to balance accuracy with simplicity. Removing every technical term could prevent readers from recognizing it on the platform, while using terms without explanation makes the content difficult to understand.

In the Spanish version of the website, we also aim to use expressions familiar to readers in Argentina, including:

“Vos.”
“Podés.”
“Tenés.”
“Retiro.”
“Comprobante.”
“DNI.”
“CBU” and “CVU” where relevant.

If You Cannot Use a Mouse

Some people cannot use a mouse or touchscreen because of tremors, limited mobility, injuries, pain, or preferences related to assistive technology.

Our objective is to make the main functions available through a keyboard. WCAG states that functionality should be accessible through a keyboard interface, which also benefits alternative devices that generate equivalent keystrokes.

Standard navigation should allow users to:

Move forward using Tab.
Move backward using Shift + Tab.
Activate links and buttons with Enter.
Activate certain controls with the Space bar.
Move between options using arrow keys.
Close components using Escape where appropriate.

The active element should display a visible focus indicator. Removing the outline without providing an alternative makes it difficult for users to know where they are on the page.

Where the template allows, skip links help users bypass repeated menus and go directly to the main content.

Action	Standard control
Move to the next element	Tab
Return to the previous element	Shift + Tab
Open a link	Enter
Activate a button	Enter or Space bar
Move between options	Arrow keys
Close a dialog box or menu	Escape
Skip repeated navigation	Skip link, where available

Not every external or embedded feature may respond in the same way. If focus becomes trapped or a button cannot be activated, report the URL and the affected element.

If You Depend on Audio Not Starting Unexpectedly

The website is based primarily on written content. We aim not to use automatically playing audio or pop-up videos that start with sound without user action.

Unexpected audio may make navigation difficult for people who:

Use screen readers.
Have sensory sensitivities.
Browse in a shared environment.
Depend on hearing aids.
Have difficulty locating the pause control.
Need a predictable environment.

When multimedia content is included, users should be able to decide when to play, pause, or stop it.

If we publish our own informational videos in the future, the objective will be to provide captions and, where reasonable, a written transcript. Essential information should not be available only through audio.

Videos or players managed by third parties may have different controls and policies. In those cases, we will attempt to provide written context, but we cannot directly modify the accessibility of an external player.

If You Are Browsing With a Weak Connection

Accessibility also depends on connection speed and stability.

In different parts of Argentina, people may access the website through variable mobile networks, limited data plans, or shared connections. A page that is too heavy may become a barrier even when its visual design meets other accessibility criteria.

For this reason, we aim to reduce unnecessary page weight through practices such as:

Image compression.
Efficient formats such as WebP or AVIF where supported.
Image dimensions adapted to the actual display area.
Lazy loading for images outside the initial visible area.
Reducing external scripts.
Reusing cached resources.
Removing heavy animations.
Maintaining a relatively simple HTML structure.

These are technical objectives and may vary depending on the template or external services being used.

On touchscreen devices, buttons and links should have a sufficiently large area and enough space between nearby controls. As a design reference, touch targets of approximately 44 × 44 CSS pixels are commonly used, although the assessment also depends on spacing, function, and context.

The main content should remain understandable even when an image takes longer to load.

Accessibility of Tables, Images, and Forms

Articles about casinos may contain many tables covering bonuses, payment methods, limits, requirements, and comparisons.

An accessible table requires a clear structure. We aim to use proper headings and avoid relying only on position or color.

When a table is too wide for a small screen, horizontal scrolling may be enabled. In these situations, readers should be able to recognize that additional content is available to one side.

Informative images require appropriate alternative text. Good alt text does not simply repeat the file name. It explains what information the image contributes to the article.

Forms should include:

Visible labels.
Brief instructions.
Clearly identified required fields.
Error messages provided in text.
A logical tab order.
Buttons with clear names.
Understandable confirmation messages.

You should not submit passwords, KYC documents, full card numbers, or OTP codes through the editorial form.

What We Cannot Fix in Embedded Content

Some articles may contain third-party materials such as platform screenshots, videos, charts, maps, regulatory documents, or links to PDF files.

The editorial team may improve the context surrounding these materials, but it cannot always modify their code, controls, or internal structure.

For example, a screenshot of an operator’s dashboard is a static image. It can be accompanied by alternative text or an explanation, but it cannot reproduce all the accessible functions of the original system.

Similarly, an external PDF document may:

Lack headings.
Use an incorrect reading order.
Contain tables that are difficult to interpret.
Fail to support suitable zoom.
Display text as an image.
Work poorly with screen readers.

Third-party content remains outside our direct control, a limitation also acknowledged in the accessibility statements of major operators such as bet365.

Where possible, we will try to compensate for these limitations with summaries, descriptions, or alternative links.

Telling Us That Something Does Not Work

Readers can report accessibility problems through the website’s contact form.

The message should include:

The page URL.
The element causing the problem.
The device being used.
The operating system.
The browser and, where known, its version.
The assistive technology being used.
A brief description of what happened.
The result you expected.

Useful examples include a link that does not receive focus, an image without a description, a table that cannot be navigated, or a form that does not communicate its errors.

You do not need to share medical information or explain a diagnosis. We only need to understand the technical or editorial barrier.

Accessibility reports are treated as a priority because they may completely prevent access to part of the website.

Our Approach to Continuous Improvement

Accessibility requires ongoing review.

A template update may remove one barrier and create another. A page may also work correctly in one browser and later develop problems after an operating-system update.

Our improvement process may include:

Automated checks after major changes.
Manual keyboard testing.
Review of headings and labels.
Contrast testing.
Evaluation using screen readers.
Image optimization.
Correction of issues reported by readers.
Monitoring new WCAG versions.

WCAG 2.2 is already available, although this document uses WCAG 2.1 Level AA as the website’s primary established benchmark. Both versions form part of the WCAG 2 framework maintained by the W3C.

We do not set a rigid schedule for every audit. Reviews may be carried out when a template changes, a new function is added, or a report is received. A broader manual assessment may be scheduled periodically or after significant structural changes.

Feedback from real users complements automated tools and may reveal obstacles that are difficult to reproduce.

Age Notice for This Page

The entire website, including this accessibility page, is intended for people aged 18 or older.

Accessibility does not change the age restrictions associated with online casinos and betting. Minors should not interpret the articles as an invitation or guide to registering on gambling platforms.

We recommend that parents and guardians:

Monitor access to betting-related content.
Use parental controls.
Avoid leaving accounts open.
Avoid saving payment methods on shared devices.
Explain the financial risks associated with gambling.

This page concerns only the accessibility of the informational resource. It does not manage casino accounts and cannot resolve accessibility problems within MyStake or another external platform.

Problems involving this website may be reported through the editorial form by providing the page, device, and a specific description of the issue.