{"id":992417,"date":"2026-06-26T07:02:45","date_gmt":"2026-06-26T07:02:45","guid":{"rendered":"https:\/\/ifdb.io\/accessibility-tree-was-der-screenreader-wirklich-liest\/"},"modified":"2026-10-12T10:30:42","modified_gmt":"2026-10-12T10:30:42","slug":"accessibility-tree-was-der-screenreader-wirklich-liest","status":"publish","type":"post","link":"https:\/\/ifdb.io\/en\/accessibility-tree-was-der-screenreader-wirklich-liest\/","title":{"rendered":"Accessibility Tree: what the screen reader actually reads"},"content":{"rendered":"\n

The accessibility tree is the most important part of your website that nobody can see. This is because a screen reader does not read your pretty pixels or your raw source code \u2013 it reads this invisible structure generated by the browser. If it is incorrect, a blind person will receive incorrect information or none at all, no matter how perfect the page looks. In this guide, I\u2019ll show you, using real-world examples, how the accessibility tree is created, what three pieces of information each node contains, why a div styled as a button simply disappears within it, and how you can see for yourself in two minutes what a screen reader actually reads out. <\/p>\n\n

What is the Accessibility Tree?<\/h2>\n\n

The Accessibility Tree is a data structure generated by the browser that acts as an interface between your code and assistive technology. The browser derives it from the DOM and reduces it to what matters for accessibility: the role, name, state and relationships of each control. In German, it could be called the \u2018Barrierefreiheitsbaum\u2019. <\/p>\n\n

What matters is what assistive technology does with it. A screen reader, voice control or switch control does not access the visible page, but this tree specifically. It is therefore the only source from which these tools draw their information. <\/p>\n\n

This leads to the central idea of this guide. Anything that is not correctly represented in the Accessibility Tree does not exist for a blind person. The visual appearance of a page is irrelevant to them \u2013 only the tree matters. That is why we always check accessibility at the level of the tree, not the design. <\/p>\n\n

Who depends on a proper tree<\/h2>\n\n

A correctly structured accessibility tree benefits a wide range of people. This is because it is not only screen readers that rely on it; voice control and switch control systems also derive their information exclusively from this tree. <\/p>\n\n

There is a wide variety of users. A blind person hears roles and names read aloud, a user with limited mobility controls the elements using voice commands, and some combine a screen magnifier with a screen reader. They all encounter the same problems as soon as the tree is incomplete. <\/p>\n\n

Then there is the legal aspect. Criterion 4.1.2 \u2018Name, role, value\u2019 is a Level A requirement and therefore an absolute minimum requirement. Anyone who neglects the tree therefore fails to meet even the lowest level of the WCAG. And it is precisely this level that has been legally binding for many providers since the BFSG came into force. <\/p>\n\n

DOM, accessibility tree, assistive technology: the chain<\/h2>\n\n

The process from code to user involves several stages. First, the browser reads the HTML and uses it to build the DOM. It then uses the DOM to calculate the accessibility tree, which contains only the information relevant to accessibility. It passes this tree on to assistive technology via an operating system interface. <\/p>\n\n

At the end of this chain lies the assistive technology. The screen reader interprets the tree and tells the user what they are dealing with. It is important to note that the assistive technology communicates with the tree, not with the DOM, and certainly not with the pixels on the screen. This single insight explains why visually appealing web pages can still be inaccessible. <\/p>\n\n

This distinction explains many of the barriers. A page may work technically and look good \u2013 yet still produce a fragmented tree. I go into more detail about how the DOM is structured in the guide to DOM structure<\/a>. <\/p>\n\n

Role, name, status: the three details for each element<\/h2>\n\n

Each node in the accessibility tree contains a small amount of crucial information. This tells the assistive technology what the element is, what it is called and what its state is. This is precisely what Success Criterion 4.1.2 \u2018Name, Role, Value\u2019 (Level A) requires. <\/p>\n\n

Information<\/th>Significance<\/th>Example<\/th><\/tr><\/thead>
Role<\/td>What is this element?<\/td>Button, link, heading, check box<\/td><\/tr>
Name<\/td>What is it called?<\/td>“Submit comment”<\/td><\/tr>
Condition \/ Value<\/td>In what condition is it?<\/td>activated, opened, deactivated<\/td><\/tr><\/tbody><\/table><\/figure>\n\n

These details are generated in different ways. Native HTML elements provide them automatically: a<button><\/code> button automatically has the \u2018button\u2019 role, and a tick box has its state. If any of these details are missing, the assistive technology does not know what the user is looking at. And in such cases, the screen reader may say nothing at all or announce something incorrect. <\/p>\n\n

How the name is determined<\/h2>\n\n

An element\u2019s accessible name is not chosen randomly, but is calculated according to a fixed order. The browser checks several possible sources and selects the one with the highest priority. Knowing this order saves a lot of guesswork. <\/p>\n\n

The order of precedence is clearly defined. At the very top is a aria-labelledby<\/code>, followed by aaria-label<\/code> , then the native reference via a label, alternative text or the visible text, and finally thetitle<\/code> attribute. A aria-label<\/code>overrides the visible label \u2013 a common pitfall when the two do not match. <\/p>\n\n

It\u2019s worth taking a closer look here. If the visible text says \u2018Find out more\u2019 aria-label<\/code> but the tag says \u2018Next\u2019, a blind person will hear \u2018Next\u2019, whilst a sighted person will read \u2018Find out more\u2019. I explore where good names come from in my guide to alternative text<\/a>. <\/p>\n\n

Why CSS doesn\u2019t change anything<\/h2>\n\n

There is one principle that surprises many developers: CSS has absolutely no effect on the accessibility tree. No matter how convincingly you style an element, its appearance does not alter what is passed on to assistive technology. The tree recognises only semantics, not visual presentation. <\/p>\n\n

This has a serious consequence. An<div><\/code>element, which looks exactly like a button thanks to CSS, is still just a meaningless node in the tree, with no role and no name. To the eye, it is a button; to a screen reader, it is nothing. <\/p>\n\n

It is exactly this gap between visual perception and semantics that lies at the root of many barriers. Anyone who tackles accessibility solely through design completely overlooks the tree. And it is the tree that matters. <\/p>\n\n

Hidden content: what disappears from the tree<\/h2>\n\n

Not everything from the DOM ends up in the accessibility tree. This is because the browser specifically removes certain elements. Anything hidden using thedisplay: none<\/code>or hidden<\/code> attributes does not appear in the tree at all \u2013 as far as assistive technology is concerned, it does not exist. <\/p>\n\n

This can be controlled deliberately using two attributes. With aria-hidden=\"true\"<\/code>, you remove an element from the tree, although it remains visible \u2013 useful, for example, for a purely decorative icon. With the presentation<\/code> role, on the other hand, you simply remove an element\u2019s semantic meaning without hiding it. <\/p>\n\n

There is a common pitfall here. A aria-hidden<\/code> in the wrong place hides important content from the screen reader, whilst it remains visible to the eye. Conversely, text that is visually hidden but not hidden from the screen reader remains in the tree \u2013 this is exactly how tooltips designed solely for screen readers work. In this way, an icon can be given an invisible but audible label. <\/p>\n\n

The most common mistake: the \u2018div\u2019-button<\/h2>\n\n

Nothing illustrates the principle as clearly as the replica button. Compare a <div onclick><\/code> with a real <button><\/code>. They behave identically when clicked with the mouse, and visually they are indistinguishable. <\/p>\n\n

In the Accessibility Tree, however, there is a world of difference. The actual button appears as a \u2018button\u2019 with its name, such as \u2018Submit comment\u2019. The div, on the other hand, appears as \u2018generic\u2019, with no role and no name. A screen reader simply says nothing about it, and voice control cannot activate it. For a blind person, the button is therefore invisible. <\/p>\n\n

The solution is remarkably simple. Use the native element that\u2019s already there. After all, a <button><\/code> element automatically provides a role, focusability and keyboard navigation \u2013 everything that a `div` would have to replicate laboriously and with a high risk of errors. I explain how native elements ensure keyboard navigation in the guide to keyboard navigation<\/a>. The simplest code is also the most accessible. <\/p>\n\n

ARIA only modifies the accessibility tree<\/h2>\n\n

Many people misunderstand what ARIA actually does. ARIA only modifies the accessibility tree \u2013 nothing else. It does not alter the appearance, behaviour or keyboard navigation, but only the role, name, state or attributes of an element in the tree. <\/p>\n\n

This leads to the first rule of ARIA. Only use ARIA if there is no suitable native element. This is because a <button><\/code> element behaves correctly out of the box, whereas with a div enhanced using ARIA, you have to replicate this behaviour yourself using a script \u2013 including all keyboard and state logic. <\/p>\n\n

Incorrect use of ARIA makes the tree worse, not better. A contradictory role or a superfluous attribute confuses the assistive technology more than it helps. I explore when ARIA is appropriate in more detail in the guide to ARIA in web applications<\/a>. <\/p>\n\n

Native HTML trumps recreated elements<\/h2>\n\n

The most reliable way to create a good tree is surprisingly simple. Use native HTML elements wherever possible. After all, each one already comes with its own correct role, state and keyboard controls \u2013 without the need for any additional code. <\/p>\n\n

The list is straightforward. A <button><\/code> provides a button, a <a href><\/code> a link, a <input><\/code> (including its type) the appropriate field, and <details><\/code> with <summary><\/code> even a drop-down element. Drop-down lists and tick boxes are also available natively. <\/p>\n\n

The alternative approach is laborious and prone to errors. Anyone recreating the same thing using a div with ARIA must add every role, every state and every keyboard interaction manually via script. More often than not, something gets left out, and the tree ends up being worse than the native original. That is why writing less code of your own is almost always the better choice here. <\/p>\n\n

Not just screen readers: voice control too<\/h2>\n\n

The Accessibility Tree is not intended solely for screen readers. Voice control systems also access the same information. If a user says \u201cClick \u2018Submit comment\u2019\u201d, the software searches the tree for an element with the role \u2018Button\u2019 and the name \u2018Submit comment\u2019. <\/p>\n\n

This makes the correct name doubly important. If the accessible name does not match the visible label, the voice control cannot find the element. The user issues a command, and nothing happens \u2013 even though the button is right in front of them. <\/p>\n\n

Switch controls and other assistive technologies also rely on this tree. A correctly structured accessibility tree therefore benefits a whole range of assistive technologies at the same time. I explain how these tools work in detail in the guide to screen readers<\/a>. A well-structured tree is therefore the common foundation for them all. <\/p>\n\n

Dynamic content: the tree must grow with it<\/h2>\n\n

Nowadays, a web page rarely remains static. If the DOM changes as a result of JavaScript, the browser also updates the accessibility tree. However, assistive technology is only made aware of such changes if the appropriate events are triggered. <\/p>\n\n

This is exactly where subtle errors arise. If a menu drops down without the state in the tree changing, a screen reader user will not notice this. You should therefore always keep states such as \u2018expanded\u2019 or \u2018selected\u2019 up to date, for example using aria-expanded<\/code>. <\/p>\n\n

The same applies to inserted messages. A new message must be actively announced, otherwise it will be overlooked (4.1.3 Status messages). The tree therefore not only reflects the initial state, but must also track every relevant change. <\/p>\n\n

View the Accessibility Tree itself<\/h2>\n\n

You don\u2019t have to guess what the Accessibility Tree looks like \u2013 you can view it directly.<\/p>\n\n

A practical example \u2013 see what the screen reader sees<\/strong>: Open the Developer Tools in Chrome and switch to the \u2018Accessibility\u2019 tab. Now select any control. In the panel, you\u2019ll see the calculated role, the accessible name along with all the sources that influence it, and the state \u2013 in other words, exactly what an assistive technology receives. Use this to check the control elements you\u2019ve created yourself: Does your stylish button appear as a \u2018Button\u2019 with a clear name? Or does it say \u2018generic\u2019 with an empty name? In the latter case, a screen reader user will hear nothing useful when focusing on it. If you prefer an even simpler approach, use an extension such as WAVE, which makes roles and names visible directly on the page. This perspective fundamentally changes the way you view your own work. <\/p>\n\n

Why overlays do not fix the tree<\/h2>\n\n

It is now clear why overlay widgets placed on top do not solve the problem. This is because an overlay operates on the visible interface or inserts surface-level ARIA code retrospectively. It cannot therefore generate a consistently correct accessibility tree. <\/p>\n\n

The incorrect or missing roles and names remain at the core. An overlay cannot reliably deduce missing semantics because it lacks an understanding of the elements\u2019 actual meaning. It merely masks the symptom rather than addressing the root cause. And as soon as the page changes, the whole process starts all over again. <\/p>\n\n

The only reliable solution is correct code. That is precisely the underlying principle of Access Code<\/a>: fixing errors where they arise \u2013 in the code, not in the visible DOM. A linter in the editor and a validation gate in the pull request ensure that the source code itself generates a clean tree. <\/p>\n\n

Common errors in the Accessibility Tree<\/h2>\n\n

The same patterns recur time and again across many audits. These are the seven I come across most often \u2013 and they all originate in the code: <\/p>\n\n

    \n
  • Interactive `div` or `span`:<\/strong> a generic node with no role or name.<\/li>\n\n\n\n
  • Missing name<\/strong>: an icon button whose accessible name is left blank.<\/li>\n\n\n\n
  • An incorrect role<\/strong> that does not correspond to the element\u2019s function.<\/li>\n\n\n\n
  • `aria-hidden`<\/strong> on important content, which then disappears from the tree.<\/li>\n\n\n\n
  • Contradictory ARIA that overrides native semantics.<\/li>\n\n\n\n
  • Name from the wrong source<\/strong>, such as an overridden aria-label<\/code>.<\/li>\n\n\n\n
  • Outdated status<\/strong> that no longer reflects the actual situation.<\/li>\n<\/ul>\n\n

    One thing stands out here. None of these errors are visible in the browser. That is precisely why they would never be noticed without looking at the tree or carrying out a test using assistive technology. <\/p>\n\n

    The Tree and automated testing<\/h2>\n\n

    Automated tools can check part of the tree, but not all of it. They reliably detect when a button has no name at all or when a role is missing. This is exactly where Access Code<\/a> comes in, flagging such errors right there in the editor. <\/p>\n\n

    However, scanners reach their limits when it comes to meaning. Whether an accessible name is truly appropriate, whether the chosen role corresponds to the function, and whether a state changes correctly in actual use cannot be assessed by machines alone. This requires human judgement. <\/p>\n\n

    That is why both levels are needed. The automated check handles the technical aspects, whilst the human check assesses the content. Only together do they provide the certainty that the tree is not only formally present but is also genuinely usable. At IFDB, we consistently follow this two-pronged approach. <\/p>\n\n

    Does your team want to fix issues in the code rather than just covering them up? In 30 minutes, we\u2019ll explain how testing and fixing fit into your day-to-day development work. <\/strong><\/p>\n\n

    \n
    Book a 30-minute Call<\/a><\/div>\n<\/div>\n\n

    Frequently Asked Questions about the Accessibility Tree<\/h2>\n\n

    To round off, here are the questions I come across most frequently in my practice. The answers are brief and to the point. <\/p>\n\n

    Is the accessibility tree the same as the DOM?<\/h2>\n\n

    No. Whilst the browser derives the tree from the DOM, it reduces it to the information relevant to accessibility. The DOM is for rendering, whilst the tree is for assistive technology. <\/p>\n\n

    Does CSS affect the accessibility tree?<\/h2>\n\n

    No. The appearance and layout do not alter the tree. A div styled as a button remains, within it, a meaningless node with no role or name. <\/p>\n\n

    What is the purpose of ARIA in the Accessibility Tree?<\/h2>\n\n

    ARIA only modifies the tree \u2013 role, name, state and attributes. It does not alter anything visually. However, native HTML elements are usually the better choice. <\/p>\n\n

    How to ensure your accessibility tree is correct<\/h2>\n\n

    The process begins with the code and ends with robust validation. Access Code<\/a> helps right from the development stage: a linter in the editor and a WCAG-Gate in the pull request catch incorrect roles, missing names and overridden semantics before they even go live. This ensures a clean tree structure right from the start. <\/p>\n\n

    Only through actual use will it become clear whether the tree is ultimately correct. Does a blind person hear the correct role and name for each element? Is every state correct? An automatic scanner alone cannot assess this. With Access Ready<\/a>, we test your application with real users of assistive technology and issue a legally compliant certificate. <\/p>\n\n

    Approach<\/th>Starts at<\/th>Correct tree<\/th>Evidence<\/th><\/tr><\/thead>
    Overlay-Widget<\/td>visible surface<\/td>no<\/td>no<\/td><\/tr>
    Pure Scanner<\/td>measurable code errors<\/td>in part<\/td>no<\/td><\/tr>
    Access Code + Access Ready (IFDB)<\/td>Source text and real-life experience<\/td>yes<\/td>yes<\/td><\/tr><\/tbody><\/table><\/figure>\n\n

    The difference lies in the approach. An overlay simply masks the surface, whereas we fix the source. This turns \u2018looks like a button\u2019 into a genuine \u2018is a button\u2019 \u2013 in the tree that the screen reader actually reads. And so a page that merely looks accessible becomes one that is accessible at its core. <\/p>\n","protected":false},"excerpt":{"rendered":"

    The accessibility tree is the most important part of your…<\/p>\n","protected":false},"author":1,"featured_media":992418,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[67],"tags":[],"class_list":["post-992417","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-development-code"],"yoast_head":"\nAccessibility Tree: what the screen reader actually reads | ifdb<\/title>\n<meta name=\"description\" content=\"The Accessibility Tree explained: What the screen reader actually reads, why CSS doesn\u2019t change anything, and how you can see for yourself what a div button outputs.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/ifdb.io\/en\/accessibility-tree-was-der-screenreader-wirklich-liest\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Accessibility Tree: what the screen reader actually reads\" \/>\n<meta property=\"og:description\" content=\"Your screen reader does not read the pixels or the DOM, but rather the accessibility tree. Why a styled div simply disappears from it.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/ifdb.io\/en\/accessibility-tree-was-der-screenreader-wirklich-liest\/\" \/>\n<meta property=\"og:site_name\" content=\"ifdb \u2013 digitale Barrierefreiheit & BFSG-Konformit\u00e4t\" \/>\n<meta property=\"article:published_time\" content=\"2026-06-26T07:02:45+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2026-10-12T10:30:42+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/ifdb.io\/wp-content\/uploads\/2026\/06\/IFDB_Blog_Accessibility-tree-funktion.jpg\" \/>\n\t<meta property=\"og:image:width\" content=\"1920\" \/>\n\t<meta property=\"og:image:height\" content=\"1280\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/jpeg\" \/>\n<meta name=\"author\" content=\"Lukas Maximilian Langer\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:title\" content=\"The most important part of your website that nobody sees\" \/>\n<meta name=\"twitter:description\" content=\"A `div` styled as a button is meaningless in the accessibility tree. What the screen reader actually reads \u2013 and how you can check this for yourself.\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Lukas Maximilian Langer\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"14 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/ifdb.io\\\/en\\\/accessibility-tree-was-der-screenreader-wirklich-liest\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/ifdb.io\\\/en\\\/accessibility-tree-was-der-screenreader-wirklich-liest\\\/\"},\"author\":{\"name\":\"Lukas Maximilian Langer\",\"@id\":\"https:\\\/\\\/ifdb.io\\\/en\\\/#\\\/schema\\\/person\\\/3dc6a516bc934cf80a07e460b9c29fab\"},\"headline\":\"Accessibility Tree: what the screen reader actually reads\",\"datePublished\":\"2026-06-26T07:02:45+00:00\",\"dateModified\":\"2026-10-12T10:30:42+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/ifdb.io\\\/en\\\/accessibility-tree-was-der-screenreader-wirklich-liest\\\/\"},\"wordCount\":2856,\"publisher\":{\"@id\":\"https:\\\/\\\/ifdb.io\\\/en\\\/#organization\"},\"image\":{\"@id\":\"https:\\\/\\\/ifdb.io\\\/en\\\/accessibility-tree-was-der-screenreader-wirklich-liest\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/ifdb.io\\\/wp-content\\\/uploads\\\/2026\\\/06\\\/IFDB_Blog_Accessibility-tree-funktion.jpg\",\"articleSection\":[\"Development & Code\"],\"inLanguage\":\"en-US\"},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/ifdb.io\\\/en\\\/accessibility-tree-was-der-screenreader-wirklich-liest\\\/\",\"url\":\"https:\\\/\\\/ifdb.io\\\/en\\\/accessibility-tree-was-der-screenreader-wirklich-liest\\\/\",\"name\":\"Accessibility Tree: what the screen reader actually reads | ifdb\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/ifdb.io\\\/en\\\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\\\/\\\/ifdb.io\\\/en\\\/accessibility-tree-was-der-screenreader-wirklich-liest\\\/#primaryimage\"},\"image\":{\"@id\":\"https:\\\/\\\/ifdb.io\\\/en\\\/accessibility-tree-was-der-screenreader-wirklich-liest\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/ifdb.io\\\/wp-content\\\/uploads\\\/2026\\\/06\\\/IFDB_Blog_Accessibility-tree-funktion.jpg\",\"datePublished\":\"2026-06-26T07:02:45+00:00\",\"dateModified\":\"2026-10-12T10:30:42+00:00\",\"description\":\"The Accessibility Tree explained: What the screen reader actually reads, why CSS doesn\u2019t change anything, and how you can see for yourself what a div button outputs.\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/ifdb.io\\\/en\\\/accessibility-tree-was-der-screenreader-wirklich-liest\\\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/ifdb.io\\\/en\\\/accessibility-tree-was-der-screenreader-wirklich-liest\\\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/ifdb.io\\\/en\\\/accessibility-tree-was-der-screenreader-wirklich-liest\\\/#primaryimage\",\"url\":\"https:\\\/\\\/ifdb.io\\\/wp-content\\\/uploads\\\/2026\\\/06\\\/IFDB_Blog_Accessibility-tree-funktion.jpg\",\"contentUrl\":\"https:\\\/\\\/ifdb.io\\\/wp-content\\\/uploads\\\/2026\\\/06\\\/IFDB_Blog_Accessibility-tree-funktion.jpg\",\"width\":1920,\"height\":1280,\"caption\":\"A person wearing headphones is sitting in front of two monitors with colour tools \u2013 Accessibility Tree: what the screen reader reads\"},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/ifdb.io\\\/en\\\/accessibility-tree-was-der-screenreader-wirklich-liest\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/ifdb.io\\\/en\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Accessibility Tree: what the screen reader actually reads\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/ifdb.io\\\/en\\\/#website\",\"url\":\"https:\\\/\\\/ifdb.io\\\/en\\\/\",\"name\":\"ifdb\",\"description\":\"Audit, Zertifizierung und Haftungsschutz f\u00fcr digitale Barrierefreiheit\",\"publisher\":{\"@id\":\"https:\\\/\\\/ifdb.io\\\/en\\\/#organization\"},\"alternateName\":\"ifdb GmbH\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/ifdb.io\\\/en\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Organization\",\"@id\":\"https:\\\/\\\/ifdb.io\\\/en\\\/#organization\",\"name\":\"ifdb GmbH\",\"alternateName\":\"ifdb\",\"url\":\"https:\\\/\\\/ifdb.io\\\/en\\\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/ifdb.io\\\/en\\\/#\\\/schema\\\/logo\\\/image\\\/\",\"url\":\"https:\\\/\\\/ifdb.io\\\/wp-content\\\/uploads\\\/2026\\\/06\\\/ifdb_logo.png\",\"contentUrl\":\"https:\\\/\\\/ifdb.io\\\/wp-content\\\/uploads\\\/2026\\\/06\\\/ifdb_logo.png\",\"width\":1366,\"height\":590,\"caption\":\"ifdb GmbH\"},\"image\":{\"@id\":\"https:\\\/\\\/ifdb.io\\\/en\\\/#\\\/schema\\\/logo\\\/image\\\/\"},\"sameAs\":[\"https:\\\/\\\/www.instagram.com\\\/ifdb.io\\\/\",\"https:\\\/\\\/www.linkedin.com\\\/company\\\/ifdb-io\\\/\"]},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/ifdb.io\\\/en\\\/#\\\/schema\\\/person\\\/3dc6a516bc934cf80a07e460b9c29fab\",\"name\":\"Lukas Maximilian Langer\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/cdcdadbe9ee8fc0e930f7635b7f8ed5e82ca93088e944c2a2caec91811b70e6d?s=96&d=mm&r=g\",\"url\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/cdcdadbe9ee8fc0e930f7635b7f8ed5e82ca93088e944c2a2caec91811b70e6d?s=96&d=mm&r=g\",\"contentUrl\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/cdcdadbe9ee8fc0e930f7635b7f8ed5e82ca93088e944c2a2caec91811b70e6d?s=96&d=mm&r=g\",\"caption\":\"Lukas Maximilian Langer\"},\"description\":\"Als Gr\u00fcnder der ifdb GmbH setzt sich Lukas Maximilian Langer daf\u00fcr ein, digitale Barrierefreiheit vom Pflichtthema zum Selbstverst\u00e4ndnis zu machen. Sein Ziel: Websites, Apps und Dokumente, die f\u00fcr alle zug\u00e4nglich sind \u2013 unabh\u00e4ngig von Einschr\u00e4nkungen.\",\"sameAs\":[\"https:\\\/\\\/ifdb.io\",\"https:\\\/\\\/www.linkedin.com\\\/in\\\/lukasmaximilianlanger\"],\"gender\":\"m\u00e4nnlich\",\"knowsAbout\":[\"Design\",\"Development\",\"digitale Barrierefreiheit\",\"EAA\",\"BFSG\",\"Marketing\",\"EN301549\"],\"knowsLanguage\":[\"Deutsch\",\"Englisch\",\"Spanisch\"],\"jobTitle\":\"Gr\u00fcnder\",\"worksFor\":\"IFDB GmbH\",\"url\":\"https:\\\/\\\/ifdb.io\\\/en\\\/author\\\/l-langerifdb-op\\\/\"}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"Accessibility Tree: what the screen reader actually reads | ifdb","description":"The Accessibility Tree explained: What the screen reader actually reads, why CSS doesn\u2019t change anything, and how you can see for yourself what a div button outputs.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/ifdb.io\/en\/accessibility-tree-was-der-screenreader-wirklich-liest\/","og_locale":"en_US","og_type":"article","og_title":"Accessibility Tree: what the screen reader actually reads","og_description":"Your screen reader does not read the pixels or the DOM, but rather the accessibility tree. Why a styled div simply disappears from it.","og_url":"https:\/\/ifdb.io\/en\/accessibility-tree-was-der-screenreader-wirklich-liest\/","og_site_name":"ifdb \u2013 digitale Barrierefreiheit & BFSG-Konformit\u00e4t","article_published_time":"2026-06-26T07:02:45+00:00","article_modified_time":"2026-10-12T10:30:42+00:00","og_image":[{"width":1920,"height":1280,"url":"https:\/\/ifdb.io\/wp-content\/uploads\/2026\/06\/IFDB_Blog_Accessibility-tree-funktion.jpg","type":"image\/jpeg"}],"author":"Lukas Maximilian Langer","twitter_card":"summary_large_image","twitter_title":"The most important part of your website that nobody sees","twitter_description":"A `div` styled as a button is meaningless in the accessibility tree. What the screen reader actually reads \u2013 and how you can check this for yourself.","twitter_misc":{"Written by":"Lukas Maximilian Langer","Est. reading time":"14 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/ifdb.io\/en\/accessibility-tree-was-der-screenreader-wirklich-liest\/#article","isPartOf":{"@id":"https:\/\/ifdb.io\/en\/accessibility-tree-was-der-screenreader-wirklich-liest\/"},"author":{"name":"Lukas Maximilian Langer","@id":"https:\/\/ifdb.io\/en\/#\/schema\/person\/3dc6a516bc934cf80a07e460b9c29fab"},"headline":"Accessibility Tree: what the screen reader actually reads","datePublished":"2026-06-26T07:02:45+00:00","dateModified":"2026-10-12T10:30:42+00:00","mainEntityOfPage":{"@id":"https:\/\/ifdb.io\/en\/accessibility-tree-was-der-screenreader-wirklich-liest\/"},"wordCount":2856,"publisher":{"@id":"https:\/\/ifdb.io\/en\/#organization"},"image":{"@id":"https:\/\/ifdb.io\/en\/accessibility-tree-was-der-screenreader-wirklich-liest\/#primaryimage"},"thumbnailUrl":"https:\/\/ifdb.io\/wp-content\/uploads\/2026\/06\/IFDB_Blog_Accessibility-tree-funktion.jpg","articleSection":["Development & Code"],"inLanguage":"en-US"},{"@type":"WebPage","@id":"https:\/\/ifdb.io\/en\/accessibility-tree-was-der-screenreader-wirklich-liest\/","url":"https:\/\/ifdb.io\/en\/accessibility-tree-was-der-screenreader-wirklich-liest\/","name":"Accessibility Tree: what the screen reader actually reads | ifdb","isPartOf":{"@id":"https:\/\/ifdb.io\/en\/#website"},"primaryImageOfPage":{"@id":"https:\/\/ifdb.io\/en\/accessibility-tree-was-der-screenreader-wirklich-liest\/#primaryimage"},"image":{"@id":"https:\/\/ifdb.io\/en\/accessibility-tree-was-der-screenreader-wirklich-liest\/#primaryimage"},"thumbnailUrl":"https:\/\/ifdb.io\/wp-content\/uploads\/2026\/06\/IFDB_Blog_Accessibility-tree-funktion.jpg","datePublished":"2026-06-26T07:02:45+00:00","dateModified":"2026-10-12T10:30:42+00:00","description":"The Accessibility Tree explained: What the screen reader actually reads, why CSS doesn\u2019t change anything, and how you can see for yourself what a div button outputs.","breadcrumb":{"@id":"https:\/\/ifdb.io\/en\/accessibility-tree-was-der-screenreader-wirklich-liest\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/ifdb.io\/en\/accessibility-tree-was-der-screenreader-wirklich-liest\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/ifdb.io\/en\/accessibility-tree-was-der-screenreader-wirklich-liest\/#primaryimage","url":"https:\/\/ifdb.io\/wp-content\/uploads\/2026\/06\/IFDB_Blog_Accessibility-tree-funktion.jpg","contentUrl":"https:\/\/ifdb.io\/wp-content\/uploads\/2026\/06\/IFDB_Blog_Accessibility-tree-funktion.jpg","width":1920,"height":1280,"caption":"A person wearing headphones is sitting in front of two monitors with colour tools \u2013 Accessibility Tree: what the screen reader reads"},{"@type":"BreadcrumbList","@id":"https:\/\/ifdb.io\/en\/accessibility-tree-was-der-screenreader-wirklich-liest\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/ifdb.io\/en\/"},{"@type":"ListItem","position":2,"name":"Accessibility Tree: what the screen reader actually reads"}]},{"@type":"WebSite","@id":"https:\/\/ifdb.io\/en\/#website","url":"https:\/\/ifdb.io\/en\/","name":"ifdb","description":"Audit, Zertifizierung und Haftungsschutz f\u00fcr digitale Barrierefreiheit","publisher":{"@id":"https:\/\/ifdb.io\/en\/#organization"},"alternateName":"ifdb GmbH","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/ifdb.io\/en\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Organization","@id":"https:\/\/ifdb.io\/en\/#organization","name":"ifdb GmbH","alternateName":"ifdb","url":"https:\/\/ifdb.io\/en\/","logo":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/ifdb.io\/en\/#\/schema\/logo\/image\/","url":"https:\/\/ifdb.io\/wp-content\/uploads\/2026\/06\/ifdb_logo.png","contentUrl":"https:\/\/ifdb.io\/wp-content\/uploads\/2026\/06\/ifdb_logo.png","width":1366,"height":590,"caption":"ifdb GmbH"},"image":{"@id":"https:\/\/ifdb.io\/en\/#\/schema\/logo\/image\/"},"sameAs":["https:\/\/www.instagram.com\/ifdb.io\/","https:\/\/www.linkedin.com\/company\/ifdb-io\/"]},{"@type":"Person","@id":"https:\/\/ifdb.io\/en\/#\/schema\/person\/3dc6a516bc934cf80a07e460b9c29fab","name":"Lukas Maximilian Langer","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/secure.gravatar.com\/avatar\/cdcdadbe9ee8fc0e930f7635b7f8ed5e82ca93088e944c2a2caec91811b70e6d?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/cdcdadbe9ee8fc0e930f7635b7f8ed5e82ca93088e944c2a2caec91811b70e6d?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/cdcdadbe9ee8fc0e930f7635b7f8ed5e82ca93088e944c2a2caec91811b70e6d?s=96&d=mm&r=g","caption":"Lukas Maximilian Langer"},"description":"Als Gr\u00fcnder der ifdb GmbH setzt sich Lukas Maximilian Langer daf\u00fcr ein, digitale Barrierefreiheit vom Pflichtthema zum Selbstverst\u00e4ndnis zu machen. Sein Ziel: Websites, Apps und Dokumente, die f\u00fcr alle zug\u00e4nglich sind \u2013 unabh\u00e4ngig von Einschr\u00e4nkungen.","sameAs":["https:\/\/ifdb.io","https:\/\/www.linkedin.com\/in\/lukasmaximilianlanger"],"gender":"m\u00e4nnlich","knowsAbout":["Design","Development","digitale Barrierefreiheit","EAA","BFSG","Marketing","EN301549"],"knowsLanguage":["Deutsch","Englisch","Spanisch"],"jobTitle":"Gr\u00fcnder","worksFor":"IFDB GmbH","url":"https:\/\/ifdb.io\/en\/author\/l-langerifdb-op\/"}]}},"_links":{"self":[{"href":"https:\/\/ifdb.io\/en\/wp-json\/wp\/v2\/posts\/992417","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/ifdb.io\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/ifdb.io\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/ifdb.io\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/ifdb.io\/en\/wp-json\/wp\/v2\/comments?post=992417"}],"version-history":[{"count":5,"href":"https:\/\/ifdb.io\/en\/wp-json\/wp\/v2\/posts\/992417\/revisions"}],"predecessor-version":[{"id":992902,"href":"https:\/\/ifdb.io\/en\/wp-json\/wp\/v2\/posts\/992417\/revisions\/992902"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/ifdb.io\/en\/wp-json\/wp\/v2\/media\/992418"}],"wp:attachment":[{"href":"https:\/\/ifdb.io\/en\/wp-json\/wp\/v2\/media?parent=992417"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/ifdb.io\/en\/wp-json\/wp\/v2\/categories?post=992417"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/ifdb.io\/en\/wp-json\/wp\/v2\/tags?post=992417"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}