Short answer: For online shops, the key text in Turkey web accessibility law is the web accessibility circular (Presidential Circular 2025/10). It requires service providers that carry out e-commerce under Law No. 6563, the Turkish e-commerce law, to make their websites and mobile apps comply with the "Checklist – Level A" of the Ministry of Family and Social Services and with WCAG 2.2 by June 2027. The checklist turns the 31 Level A criteria of WCAG 2.2 into 126 questions, and every web page and every app screen is assessed separately. The implementing Directive (Yönerge) calls for a Review Commission of at least three people and a review in three stages: automated tests, manual tests and testing with disabled users. The circular sets no direct fine. However, monitoring results will be made public, and an inaccessible digital service can become the subject of a discrimination complaint to TİHEK, the national human rights and equality body.
We wrote this guide for owners, e-commerce managers and IT or product leads at online retailers that run their own web shop or iOS/Android app. It is also for international brands that sell into Türkiye or work with Turkish e-commerce partners. First-wave organisations such as banks and private hospitals, whose deadline ended in June 2026, can use the same steps. We did not rely on news summaries. We read the circular, the checklist, the logo guide, the Directive, the relevant laws and the TİHEK and W3C sources directly. This article is not legal advice. It is up to date as of 31 October 2026.
What does Turkey web accessibility law regulate? Four official documents in one table
The legal basis is Law No. 5378 on Persons with Disabilities:
"It shall be ensured that information services and information and communication technology are accessible to persons with disabilities." (Law No. 5378, Art. 7; our translation)
Four documents set out the details:
| Document | What does it regulate? | What it means for e-commerce |
|---|---|---|
| Circular 2025/10 (Official Gazette, 21 June 2025) | Scope and deadlines; the Monitoring, Advisory and Review Commissions; the 2-year right to use the logo | 2-year deadline: June 2027 |
| Directive on Implementation Procedures and Principles (no approval date given) | Commissions, review method, exemptions, logo procedure | A commission of at least 3 people, three-stage testing |
| Checklist – Level A (V2.2.30.01, Ankara 2026) | The 31 Level A criteria of WCAG 2.2, as 126 questions | Every page and every app screen is assessed separately |
| Accessibility Logo Usage Guide (amended 14 April 2026) | How the logo is used on websites and mobile apps | Used only on sites and apps that have been granted the right |
Two points that are often confused:
- Circular 2026/1 is not a web plan. The Monitoring and Inspection Plan in this circular, dated 21 January 2026, covers only buildings, open spaces and public transport vehicles. As of 31 October 2026, we could not find the planned Monitoring Plan for web and mobile on the accessibility and legislation pages of EYHGM, the Ministry's General Directorate of Services for Persons with Disabilities and the Elderly. It is too early to say that "e-commerce audits have started".
- A Turkish WCAG 2.2 guide does not appear to have been published yet. The guide announced in the circular is not on the Ministry's accessibility page, and W3C lists the authorised Turkish translation as "planned" (notification of intent: 5 May 2026). Use W3C's English WCAG 2.2 text as your reference.
A note on the Directive: The Ministry lists the Directive on EYHGM's Directives (Yönergeler) page. On 31 October 2026, the document link there was empty, but the PDF text is available on the Ministry's website. The text has no approval date; under Article 19, it enters into force on the date it is approved. The information on the Directive below is based on this text, so check for any updates from the Ministry.
Who does the circular cover in e-commerce, and is there a fine for non-compliance?
Scope: everyone with their own site or app
The circular names service providers that carry out electronic commerce under Law No. 6563. It sets no size threshold and no exemption for micro-enterprises. Under Law No. 6563, a service provider is a natural or legal person that carries out e-commerce, and an e-commerce environment is a website, mobile site or mobile app. A brand with its own shop or app is clearly covered. Two situations are unclear:
- Sellers that only sell on marketplaces: Law No. 6563 also counts those who sell on a marketplace as "electronic commerce service providers". However, the sales environment belongs to the marketplace, and no rule says how the obligation applies to the seller.
- Sole proprietorships: The Directive defines the commission in terms of "institutions, organisations and legal persons" and "at least three staff members", so it is unclear how the rule applies to them.
Ask the Ministry or your legal adviser for an opinion on these points. For first-wave organisations such as banks, private hospitals, private education institutions and passenger carriers, the 1-year deadline ended in June 2026.
Sanctions: no fine in the circular, but risk elsewhere
- The circular and the Directive set no administrative fines. However, the Minister will announce the monitoring results to the public.
- The fines in Law No. 5378 are not for websites. The fines in its Provisional Article 3 relate to buildings, open spaces and public transport. The figure of "5,000–25,000 TL per finding" quoted in some guides is the range this provision sets for municipalities and public bodies. For natural persons and private-law legal entities, the nominal amount in the text of the law is 1,000–5,000 TL (Turkish lira) per finding.
- The TİHEK route is a real risk. Law No. 6701, which set up TİHEK, prohibits discrimination based on disability and treats a failure to make reasonable accommodation as discrimination. It also covers natural persons and private-law legal entities that offer "similar services". The administrative fine under Article 25(1) is 17,052–256,357 TL in 2026, and TİHEK's Board can convert the fine into a warning once. In decision 2024/403, TİHEK found a violation because parts of a bank's internet and mobile banking could not be read with a screen reader.
- If you sell to consumers in Germany: the BFSG. The BFSG is the German law that implements the European Accessibility Act (Directive (EU) 2019/882). It covers e-commerce services offered to consumers after 28 June 2025, and the fine for offering a non-compliant service can reach €100,000. Micro-enterprises that provide services are exempt: those with fewer than 10 employees and an annual turnover or balance sheet total of no more than €2 million.
How do you read the accessibility checklist (Level A)?
The Ministry's 2026 checklist (V2.2.30.01) turns the 31 success criteria under the four principles of WCAG 2.2 into 126 numbered questions. We refer to them as Q1 to Q126. There are three types of question:
- ★ (64 questions): mandatory condition. A "No" answer means a fix is needed.
- ★★ (3 questions): a condition that must not exist. A "Yes" answer means a fix is needed: information given only by colour (Q52), flashing above the thresholds (Q81), and a change of context when a component merely receives focus (Q106).
- No star (59 questions): routing. For example, one question asks whether the page has a CAPTCHA, and the answer tells you which section to go to next.
The decisive rule: the questions are answered separately for every web page and every app screen. In a shop with thousands of product pages, this means working template by template: home page, category, product detail, basket, checkout steps, account and campaign pages. A fix in a template carries over to every page that uses it. Under the Directive, the Monitoring Commission will decide how pages are sampled during monitoring.
The checklist covers Level A only. Colour contrast (1.4.3), focus visible (2.4.7) and target size (2.5.8) are AA criteria, so they are outside the legal minimum. Even so, we recommend building them into your design system from the start: in WebAIM's 2026 analysis, low contrast is the most common error, found on 83.9% of home pages. The checklist may not be reproduced for commercial purposes, so we explain its logic instead of copying the questions. Download the current version from the Ministry's website.
What does the accessibility Directive require? Commission, testing, exemptions and logo
Review Commission: at least three people from your own staff
Under Article 13 of the Directive, every institution and legal person to be monitored sets up a Review Commission (İnceleme Komisyonu) of at least three staff members, at least one of whom works in the web/mobile unit. The advice in some guides that "a core team of two is enough" contradicts Article 13. In the year you are included in the Monitoring Plan (İzleme Planı), the commission prepares a Review Report in that plan's format and sends it to the secretariat at EYHGM. It also follows up on fixes and prepares an updated report for logo renewal.
How is accessibility testing done? Three stages
- Automated testing: with tools listed on the W3C website. As of 31 October 2026, W3C's list contains 119 tools. It has Android and iOS filters, and WAVE and axe DevTools are on the list (W3C does not endorse specific products).
- Manual testing: forms, interface controls, dialog boxes, data entry confirmations, error messages, feedback, the keyboard, and non-text content such as photos, video, CAPTCHA and audio.
- Testing with disabled users: involving users with visual impairments (screen reader users and users with low vision), hearing impairments (deaf and hard of hearing users) and orthopaedic impairments (limited use of a mouse and keyboard). Testing with users who have cognitive disabilities, users on the autism spectrum, users with specific learning difficulties and colour-blind users is also recommended.
Why is an accessibility overlay (plugin) not enough?
The checklist requires the link between labels and form fields, and the heading hierarchy, to be defined "programmatically" in the code. It also requires focus management to be set up correctly. A widget added afterwards tries to patch these in the browser by guesswork. It can break when templates change, and it cannot reach native iOS or Android screens at all. None of the four documents contains a provision that treats an overlay as proof of compliance. Under the Directive, manual tests and testing with disabled users are required in every case.
Know the limits of automated testing as well. According to the WebAIM Million 2026 analysis, 95.9% of the home pages of the top one million websites have automatically detected WCAG errors. The average is 56.1 errors per page, compared with 66.2 on Turkish-language pages and 71.0 in the shopping category. A keyboard trap or meaningless alt text, on the other hand, usually only shows up when people test the site. Connecting automated checks to your CI/CD pipeline helps stop fixed errors from coming back in new releases.
Exemptions: what is out of scope?
- Content added dynamically and automatically from other sources: The Directive gives dynamic ads and shopping reviews as examples. What is exempt is the content itself, not your review form or rating component.
- Online maps, as long as the essential information for navigation is provided in an accessible form.
- Live broadcasts; however, a recording of the broadcast kept on the site must be made accessible within 14 days.
- Video and audio recorded before the circular, and archived content that is not updated within one year of the circular's entry into force and is not needed for administrative processes. For new product videos, the questions on captions, transcripts and audio description (Q17–25) apply.
Turkish Sign Language (TİD) interpretation is not mandatory for video and audio content. If you provide it, the interpreter must have scored at least 70 points in the TİD Proficiency Exam.
How do you get the accessibility logo?
You cannot add the logo yourself. You can apply to EYHGM for the right to use it. The Monitoring Commission grants the right for 2 years, separately for accessible websites and for accessible apps on each mobile operating system. Renewal requires an up-to-date Review Report that follows the Monitoring Plan in force. Under the Guide, as updated on 14 April 2026, the logo may only be used on the site or app that has been granted the right. When clicked, it must lead to the verification page on EYHGM's official website, and it may not be used for commercial gain.
From storefront to checkout: the most common problems on e-commerce sites
Typical shop components and the related checklist questions (numbered as in V2.2.30.01):
| Component | Questions | What to do |
|---|---|---|
| Menu and repeated blocks | Q36–37, Q65–66, Q82–83 | Use <nav>. A submenu that opens with the mouse must also open with the keyboard. Add a "Skip to main content" link. |
| Slider and scrolling promotion banner | Q75–78 | A pause button for automatic movement that lasts more than 5 seconds. |
| Product images | Q1–5 | A meaningful alt for images that carry information; alt="" for decorative images. |
| Colour and size selector | Q16, Q51–53 | Show the selected or out-of-stock state in text as well as colour. Give each colour swatch an accessible name ("Navy blue"). |
| Filters | Q40–41, Q107–108 | Group the options with <fieldset> and <legend>. If a selection reloads the page by itself, say so in advance or add an "Apply" button. |
| Basket +/− and icon buttons | Q15–16, Q124–126 | Accessible names such as "Increase quantity" and "Add to basket"; keep the quantity value up to date programmatically. |
| Quick view, cookie banner, pop-up | Q61–64, Q69–70 | Use role="dialog" on the modal window. Focus should move into the window, Escape should close it, and on closing, focus should return to the button that opened it or to another logical point. |
| Session and basket time limits | Q73–74 | Let users turn off the time limit or extend it to at least 10 times its length, or warn them at least 20 seconds before it ends and let them extend it with a single action, at least 10 times. |
| Forms | Q38–39, Q111–120 | Placeholder text does not replace a label. Link the error text to its field. An asterisk without explanation, or a red border alone, is not enough. |
| Delivery and billing address | Q121–122 | A "Billing address is the same as delivery address" option and autocomplete attributes. |
| CAPTCHA | Q10–12 | Text that explains its purpose and an alternative that does not rely on a single sense. A visual-only or audio-only CAPTCHA is not enough. |
| Live support, FAQ, chatbot | Q109–110 | The help link in the same, predictable place on every page. |
Announcing an "Added to basket" message to screen readers (WCAG 4.1.3) is an AA criterion and is not on the checklist. Even so, we recommend it as standard practice.
The payment step and 3D Secure
The 3D Secure screen is usually a page of the bank or the payment provider, and you cannot change its content. We do not recommend relying on the Directive's exemption for automatically added content. The Directive gives examples such as ads and shopping reviews for this exemption, and in our view a purchase flow does not fit that description. Strengthen the part you control:
- Give the iframe that contains the payment fields or the 3DS screen a meaningful
title. Move focus into it when it opens, and to the result message when it closes. - Test the success and error pages after the 3DS return with a screen reader. If there is an error, keep the information the user has entered.
- Ask your payment provider for written accessibility information on the payment form and the 3DS screen, and make it a criterion when you renew the contract.
For integration details, see our guide to virtual POS (online card payment) and 3DS integration.
Mobile app accessibility: iOS, Android and React Native equivalents
The checklist names platform APIs in its examples, and your iOS and Android apps are assessed with the same questions, screen by screen. Common equivalents:
| Need (question) | Android | iOS | React Native |
|---|---|---|---|
| Accessible name (Q3, Q16) | contentDescription | accessibilityLabel | accessibilityLabel |
| Hiding a decorative element (Q5) | importantForAccessibility="no" | isAccessibilityElement = false | aria-hidden={true} |
| Heading (Q28) | accessibilityHeading="true" | accessibilityTraits = .header | accessibilityRole="header" |
| List information (Q30) | CollectionInfo | accessibilityContainerType | role="list" |
| Modal and focus (Q62, Q70) | accessibilityPaneTitle | accessibilityViewIsModal | accessibilityViewIsModal (iOS only) |
| An action instead of swiping or dragging (Q68, Q96) | AccessibilityAction | accessibilityCustomActions | accessibilityActions |
| Autofill (Q122) | autofillHints | textContentType | autoComplete |
In two places in the React Native column, we have departed from the checklist's examples. "list" is not one of the accessibilityRole values; the list role is set with role="list". On Android, accessible={false} only turns off focusability; to hide a decorative element from screen readers on both platforms, use aria-hidden. The checklist does not mention Flutter; there, the same information is provided through the label, header, excludeSemantics and customSemanticsActions properties of the Semantics widget. Also add a button alternative for actions that only work by swiping, such as removing an item from the basket (Q95–96), and an alternative and an off switch for motion-based features such as "shake to undo" (Q101–103). Link error messages to the relevant field (setError on Android). Because the logo right is granted separately for each mobile operating system, plan iOS and Android as separate products. Do not call an app "accessible" until you have tested it with VoiceOver and TalkBack. We describe our approach on the native side on our mobile app development page.
A 7-month roadmap to June 2027, step by step
A realistic sequence for a team that starts in November 2026:
- November 2026, organisation and inventory: Set up the Review Commission (at least 3 people, one of them from the web/mobile unit). List your web templates and app screens, and flag third-party components such as payment, cookie and live support tools separately.
- December 2026, baseline measurement: Run an automated scan with tools from the W3C list, then go through the checklist template by template. Turn the findings into a work list, with the ★★ items and the payment flow first.
- January–March 2027, component fixes: Fix buttons, form fields, modals, menus, sliders and filters in the design system, and connect automated tests to the CI pipeline.
- March–April 2027, payment and apps: Payment and the 3DS return, the cookie banner and third-party widgets; iOS and Android fixes.
- April–May 2027, manual tests and testing with disabled users: Keyboard, VoiceOver and TalkBack tests; sessions with users from the disability groups listed in the Directive; a draft Review Report.
- June 2027 and after: When the web/mobile Monitoring Plan is published, adapt the report to its format, consider applying for the logo, and run regression tests with every release.
Decision point: If you use an off-the-shelf theme, some of the fixes depend on your theme and plugin vendors. Get a written accessibility timeline from the vendor. If you cannot get one, consider a theme change or a custom-designed website before March 2027. With a custom design, fixes are made in shared components and carry over to every page that uses them.
How Partnerfy can help
We fix accessibility at the source, not with an overlay. First, we take an inventory of your templates and app screens and scan them with tools from the W3C list. Then we test manually with the keyboard, VoiceOver and TalkBack. We fix the findings in your design system components and in native iOS, Android or React Native code, and connect automated checks to your CI pipeline. For testing with disabled users, we prepare the scenarios, help you plan these tests with associations and organisations that work in this field, and produce the technical documentation for your Review Commission's report. Commission membership and the legal assessment stay with you. If you would like an initial assessment of your e-commerce platform, contact us.
Sources
- Official Gazette: Circular 2025/10 (21 June 2025, Issue 32933), in Turkish
- Ministry of Family and Social Services: Checklist – Level A (V2.2.30.01), in Turkish
- EYHGM: Directives page and Directive on Implementation Procedures and Principles (PDF), in Turkish
- EYHGM: Logo Usage Guide, Circular 2026/1 and accessibility page, in Turkish
- Legislation: Laws No. 5378, 6701 and 6563, in Turkish
- TİHEK: 2026 administrative fines and press release on Circular 2025/10, in Turkish
- W3C: WCAG 2.2 and WCAG translations
- W3C: Web Accessibility Evaluation Tools List
- WebAIM: The WebAIM Million (2026)
- BFSG: § 1, § 2, § 3 and § 37, in German
- React Native: Accessibility and Flutter: Semantics class