# html elements

Published articles for html elements.

This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles.

## Using and Styling the Dialog Element

DevFeed: [Using and Styling the Dialog Element](<https://devfeed.tech/articles/using-and-styling-the-dialog-element-4265.md>)

Original publisher: [Read original article](<https://css-tricks.com/using-and-styling-the-dialog-element/>)

Author: Geoff Graham

Published: 2026-08-07T14:06:43Z

Content type: tutorial

Language: en

Sources: [CSS-Tricks](<https://devfeed.tech/sources/css-tricks.md>)

Topics: [dialog](<https://devfeed.tech/topics/dialog.md>), [HTML](<https://devfeed.tech/topics/html.md>), [JavaScript](<https://devfeed.tech/topics/javascript.md>), [Web Development](<https://devfeed.tech/topics/web-development.md>)

Tags: [architecture](<https://devfeed.tech/tags/architecture.md>), [articles](<https://devfeed.tech/tags/articles.md>), [articles-guides](<https://devfeed.tech/tags/articles-guides.md>), [dialog](<https://devfeed.tech/tags/dialog.md>), [guides](<https://devfeed.tech/tags/guides.md>), [html](<https://devfeed.tech/tags/html.md>), [html-elements](<https://devfeed.tech/tags/html-elements.md>), [javascript](<https://devfeed.tech/tags/javascript.md>), [web](<https://devfeed.tech/tags/web.md>)

### AI overview

A practical guide to using the native HTML <dialog> element, covering basic markup, opening dialogs with JavaScript, modal behavior, backdrops, focus, closing methods, declarative HTML approaches, and experimental invoker commands.

### Source excerpt

There's a lot of nuance to the <dialog> element, a seemingly little piece of web architecture. I've got some notes from digging into it. Using and Styling the Dialog Element originally handwritten and published with love on CSS-Tricks. You should really get the newsletter as well.

## A refreshing take: using serverside rendering to reduce fragile DOM state

DevFeed: [A refreshing take: using serverside rendering to reduce fragile DOM state](<https://devfeed.tech/articles/a-refreshing-take-using-serverside-rendering-to-reduce-fragile-dom-state-29998.md>)

Original publisher: [Read original article](<https://engineering.freeagent.com/2025/10/17/a-refreshing-take-using-serverside-rendering-to-reduce-fragile-dom-state/>)

Author: Simon Fish

Published: 2025-10-17T08:33:59Z

Content type: article

Language: en

Sources: [FreeAgent](<https://devfeed.tech/sources/freeagent.md>)

Topics: [Hotwire](<https://devfeed.tech/topics/hotwire.md>), [Front end](<https://devfeed.tech/topics/frontend.md>), [Rails](<https://devfeed.tech/topics/rails.md>), [Stimulus](<https://devfeed.tech/topics/stimulus.md>), [WebSocket](<https://devfeed.tech/topics/websocket.md>), [Document Object Model (DOM)](<https://devfeed.tech/topics/dom.md>), [tbox](<https://devfeed.tech/topics/tbox.md>)

Tags: [browser](<https://devfeed.tech/tags/browser.md>), [development](<https://devfeed.tech/tags/development.md>), [frontend](<https://devfeed.tech/tags/frontend.md>), [hotwire](<https://devfeed.tech/tags/hotwire.md>), [html-elements](<https://devfeed.tech/tags/html-elements.md>), [js](<https://devfeed.tech/tags/js.md>), [rails](<https://devfeed.tech/tags/rails.md>), [ruby-on-rails](<https://devfeed.tech/tags/ruby-on-rails.md>), [stimulus](<https://devfeed.tech/tags/stimulus.md>), [streams](<https://devfeed.tech/tags/streams.md>), [websocket](<https://devfeed.tech/tags/websocket.md>)

### AI overview

This article examines FreeAgent's use of server-side rendering with Hotwire, Turbo, Stimulus, and Rails to reduce fragile DOM state. It explains how Turbo Streams and Action Cable can update browser pages asynchronously, contrasting these behaviors with the original DOM-manipulation actions.

### Source excerpt

Hotwire is central to how we drive the frontend at FreeAgent, and Action Cable allows us to send Turbo Streams as users browse the site, adding a layer of richness to the user experience.

## Mastering UI Testing for Android web forms

DevFeed: [Mastering UI Testing for Android web forms](<https://devfeed.tech/articles/mastering-ui-testing-for-android-web-forms-23704.md>)

Original publisher: [Read original article](<https://engineering.theblueground.com/mastering-ui-testing-for-android-web-forms/>)

Author: Vaios Tsitsonis

Published: 2024-01-05T11:50:19Z

Content type: tutorial

Language: en

Sources: [Blueground Engineering blog](<https://devfeed.tech/sources/blueground-engineering-blog.md>)

Topics: [Android](<https://devfeed.tech/topics/android.md>), [Testing](<https://devfeed.tech/topics/testing.md>), [WebView](<https://devfeed.tech/topics/webview.md>), [Forms](<https://devfeed.tech/topics/forms.md>), [JavaScript](<https://devfeed.tech/topics/javascript.md>), [HTML](<https://devfeed.tech/topics/html.md>)

Tags: [android](<https://devfeed.tech/tags/android.md>), [forms](<https://devfeed.tech/tags/forms.md>), [html-elements](<https://devfeed.tech/tags/html-elements.md>), [javascript](<https://devfeed.tech/tags/javascript.md>), [testing](<https://devfeed.tech/tags/testing.md>), [ui-testing](<https://devfeed.tech/tags/ui-testing.md>), [web](<https://devfeed.tech/tags/web.md>), [webview](<https://devfeed.tech/tags/webview.md>)

### AI overview

This tutorial explains a UI-testing problem in Android apps that open web forms in a WebView. Programmatically changing HTML input values can mark related JavaScript events as non-trusted, leaving a button disabled even when the fields display values.

### Source excerpt

Yeah! We are Android engineers! 🎉 We can build almost anything by ourselves and make it run on any Android device! But sometimes we may need to use a third-party library or incorporate web-based functionality into a WebView to go fast. This can introduce challenges during UI testing.

## Mitigating DOM clobbering attacks in JavaScript

DevFeed: [Mitigating DOM clobbering attacks in JavaScript](<https://devfeed.tech/articles/mitigating-dom-clobbering-attacks-in-javascript-8017.md>)

Original publisher: [Read original article](<https://snyk.io/blog/mitigating-dom-clobbering-attacks-javascript/>)

Author: Keshav Malik

Published: 2023-08-07T05:00:00Z

Content type: article

Language: en

Sources: [Blog RSS Feed | Snyk](<https://devfeed.tech/sources/blog-rss-feed-snyk.md>)

Topics: [Document Object Model (DOM)](<https://devfeed.tech/topics/dom.md>), [JavaScript](<https://devfeed.tech/topics/javascript.md>), [Application Security](<https://devfeed.tech/topics/application-security.md>), [web applications](<https://devfeed.tech/topics/web-applications.md>), [Vulnerabilities](<https://devfeed.tech/topics/vulnerabilities.md>), [HTML](<https://devfeed.tech/topics/html.md>)

Tags: [application-security](<https://devfeed.tech/tags/application-security.md>), [attacks](<https://devfeed.tech/tags/attacks.md>), [awareness](<https://devfeed.tech/tags/awareness.md>), [blog](<https://devfeed.tech/tags/blog.md>), [browser](<https://devfeed.tech/tags/browser.md>), [code-security](<https://devfeed.tech/tags/code-security.md>), [contentlab](<https://devfeed.tech/tags/contentlab.md>), [developer](<https://devfeed.tech/tags/developer.md>), [html](<https://devfeed.tech/tags/html.md>), [html-elements](<https://devfeed.tech/tags/html-elements.md>), [javascript](<https://devfeed.tech/tags/javascript.md>), [security](<https://devfeed.tech/tags/security.md>), [snyk-code](<https://devfeed.tech/tags/snyk-code.md>), [snyk-open-source](<https://devfeed.tech/tags/snyk-open-source.md>), [time](<https://devfeed.tech/tags/time.md>), [web-applications](<https://devfeed.tech/tags/web-applications.md>), [xss](<https://devfeed.tech/tags/xss.md>)

### AI overview

This article explains DOM clobbering, a condition in which HTML element IDs or name attributes conflict with global JavaScript variables or functions. It describes how browsers create global variables from these attributes, how conflicts can overwrite existing functions, and how attackers may exploit the behavior to cause unpredictable behavior or security vulnerabilities such as cross-site scripting (XSS).

### Source excerpt

This article explores the concept of DOM clobbering and provides strategies for building more secure and robust web applications.

## A guide to troublesome UI components

DevFeed: [A guide to troublesome UI components](<https://devfeed.tech/articles/a-guide-to-troublesome-ui-components-9362.md>)

Original publisher: [Read original article](<https://a11yproject.com/posts/a-guide-to-troublesome-ui-components/>)

Author: Martin Lexelius

Published: 2023-02-14T00:00:00Z

Content type: tutorial

Language: en

Sources: [The A11Y Project](<https://devfeed.tech/sources/the-a11y-project.md>)

Topics: [Accessibility](<https://devfeed.tech/topics/accessibility.md>), [User interface design](<https://devfeed.tech/topics/ui-design.md>), [User experience (UX)](<https://devfeed.tech/topics/ux.md>), [Web Development](<https://devfeed.tech/topics/web-development.md>), [aria](<https://devfeed.tech/topics/aria.md>), [HTML](<https://devfeed.tech/topics/html.md>), [Code quality](<https://devfeed.tech/topics/code-quality.md>), [html elements](<https://devfeed.tech/topics/html-elements.md>)

Tags: [accessibility](<https://devfeed.tech/tags/accessibility.md>), [aria](<https://devfeed.tech/tags/aria.md>), [article](<https://devfeed.tech/tags/article.md>), [code-quality](<https://devfeed.tech/tags/code-quality.md>), [guide](<https://devfeed.tech/tags/guide.md>), [how-to](<https://devfeed.tech/tags/how-to.md>), [html](<https://devfeed.tech/tags/html.md>), [html-elements](<https://devfeed.tech/tags/html-elements.md>), [ui](<https://devfeed.tech/tags/ui.md>), [ux](<https://devfeed.tech/tags/ux.md>), [web](<https://devfeed.tech/tags/web.md>)

### AI overview

A guide to designing and implementing troublesome UI components accessibly. It explains why accessibility should be planned early and highlights keyboard interaction, focus management, screen-reader announcements, correct HTML elements, ARIA attributes, and code quality.

### Source excerpt

A common opinion is that accessibility is expensive, and that if you think accessibility is expensive, you can deal with it later. Here's the twist: it will be expensive if you deal with it later. However, accessibility is not expensive if you discuss it as a team early in the process. It is possible to build just about anything, it comes down to time and money. But no client ever has said, "Hey, we have a lot of time and money!" Accessibility is not expensive if you proactively plan for it. That's why you need to learn how to avoid some of the common pitfalls. Before we start User interface (UI) elements are the parts we use to build apps or websites, such as links, accordions and checkboxes etc. Some UI components are more complicated than other components. And some components are really complicated. All roles that build for the web (product owners, UX designers, art directors, developers, QA engineers) must know this. The challenges The components in this article all have the following challenges in common: Keyboard interaction. Everything that can be done with a mouse, must be possible to do with a keyboard. This includes navigating, opening and closing items, activating, stopping, starting, selecting, etc. Focus appearance and management. Users navigating by keyboard must know where they are. Always show the user's current position in the interface. The focus order should be logical and intuitive. Consistent announcements. All events and interactions should correspond as understandable and relevant audio feedback in screen readers. Buttons should describe themselves as buttons, links as links, etc. Code quality. Using the correct elements and ARIA attributes, as well as valid HTML. The components Following are some UI components that have non-trivial considerations to use in an accessible way: Custom selects Native HTML <select> elements (sometimes referred to as dropdowns, not to be confused with disclosures) has the most understandable and usable experience a

## Aria-Label is Not Always the Answer

DevFeed: [Aria-Label is Not Always the Answer](<https://devfeed.tech/articles/aria-label-is-not-always-the-answer-38440.md>)

Original publisher: [Read original article](<https://eevis.codes/blog/2021-11-29/aria-label-is-not-always-the-answer/>)

Author: Eevis Panula

Published: 2023-01-03T08:57:28.550000Z

Content type: tutorial

Language: en

Sources: [Eevis Blog](<https://devfeed.tech/sources/eevis-blog.md>)

Topics: [Accessibility](<https://devfeed.tech/topics/accessibility.md>), [aria](<https://devfeed.tech/topics/aria.md>), [HTML](<https://devfeed.tech/topics/html.md>), [html elements](<https://devfeed.tech/topics/html-elements.md>), [W3C](<https://devfeed.tech/topics/w3c.md>)

Tags: [accessibility](<https://devfeed.tech/tags/accessibility.md>), [accessible](<https://devfeed.tech/tags/accessible.md>), [aria](<https://devfeed.tech/tags/aria.md>), [details](<https://devfeed.tech/tags/details.md>), [html](<https://devfeed.tech/tags/html.md>), [html-elements](<https://devfeed.tech/tags/html-elements.md>), [w3c](<https://devfeed.tech/tags/w3c.md>)

### AI overview

This tutorial explains that aria-label is not universally appropriate or consistently supported across HTML elements. It describes when to use aria-label, when aria-labelledby is preferable, and the element types where aria-label works consistently with assistive technologies.

### Source excerpt

Okay, you've learned about accessibility and that there is sometimes a need to make, for example, the link text more descriptive for screen reader users. You've learned about the aria-label-attribute, and its powers. It's the answer to everything! I'm afraid I have to say that it is not. It doesn't work with all HTML elements. In this blog post, I'll dig a bit deeper into the aria-label-attribute, and its usage and limitations, and options. What Is aria-label? So, let's first talk about the specification and where to use it. W3C Recommendation for Accessible Rich Internet Applications (WAI-ARIA)-document defines aria-label as "a string value that labels the current element." You can use it to provide a recognizable name of the object if there is no visible text on the screen that could be used as the label. If there was, aria-labelledby should be used. The most important thing, and the reason I'm writing this article, is that developers should use it only with the following elements: interactive elements (such as links, buttons, inputs et cetera) Elements that have a landmark role Elements that have an ARIA-widget role img or iframe-elements Source: Short note about aria-label, aria-labelledby and aria-describedby by Léonie Watson. aria-label on these elements works consistently with assistive technologies. The support is inconsistent if you use it with any other tag, such as div or span. More about that in Aria-label and non-supported elements. Let's look into each one of these elements a bit more. Interactive Elements Interactive elements are tags intended for user interaction. It means, for example, button, a (when href-attribute is present), input , details and others. The main idea is that users can interact with them. Elements with Landmark Role Elements can have landmark roles either implicitly or explicitly. Having an implicit role means that some of the HTML elements have roles set to them natively. The explicit role, on the other hand, is set with role-att

## My Advice to a Developer New to Accessibility

DevFeed: [My Advice to a Developer New to Accessibility](<https://devfeed.tech/articles/my-advice-to-a-developer-new-to-accessibility-38446.md>)

Original publisher: [Read original article](<https://eevis.codes/blog/2022-07-22/my-advice-to-a-developer-new-to-accessibility/>)

Author: Eevis Panula

Published: 2023-01-03T08:57:33.125000Z

Content type: tutorial

Language: en

Sources: [Eevis Blog](<https://devfeed.tech/sources/eevis-blog.md>)

Topics: [Accessibility](<https://devfeed.tech/topics/accessibility.md>), [Web Development](<https://devfeed.tech/topics/web-development.md>), [HTML](<https://devfeed.tech/topics/html.md>), [keyboard](<https://devfeed.tech/topics/keyboard.md>), [markup](<https://devfeed.tech/topics/markup.md>)

Tags: [accessibility](<https://devfeed.tech/tags/accessibility.md>), [accessible](<https://devfeed.tech/tags/accessible.md>), [advice](<https://devfeed.tech/tags/advice.md>), [developer](<https://devfeed.tech/tags/developer.md>), [development](<https://devfeed.tech/tags/development.md>), [element](<https://devfeed.tech/tags/element.md>), [elements](<https://devfeed.tech/tags/elements.md>), [focus](<https://devfeed.tech/tags/focus.md>), [html](<https://devfeed.tech/tags/html.md>), [html-elements](<https://devfeed.tech/tags/html-elements.md>), [input](<https://devfeed.tech/tags/input.md>), [interaction](<https://devfeed.tech/tags/interaction.md>), [interactive](<https://devfeed.tech/tags/interactive.md>), [keyboard](<https://devfeed.tech/tags/keyboard.md>), [learning](<https://devfeed.tech/tags/learning.md>), [markup](<https://devfeed.tech/tags/markup.md>)

### AI overview

This beginner-oriented accessibility article recommends focusing on progress rather than perfection and introduces semantic HTML, keyboard navigation, and listening to people with disabilities. It explains that semantic elements communicate meaning to browsers and developers and support appropriate interaction, while a div styled as a button may work only for mouse users and may not be focusable or keyboard-accessible.

### Source excerpt

Learning about accessibility for the first time can feel overwhelming. You start reading, and at some point, it hits you: There is so much to learn! And if you're like me and feel that it's your responsibility to make the things you create accessible, that might even make you feel anxious. And yes, there is a lot to learn regarding accessibility. But you don't need to know everything at once. As Meryl Evans reminds us in her tweet (and a blog post the tweet links to), it's about progress over perfection: https://twitter.com/merylkevans/status/1547635550466674692 So, here are some things I wish I had known when I first started learning accessibility. Heck, I wish I had known these things when I started learning web development! I'll share semantic HTML, keyboard navigation, and listening to people with disabilities. Learn Semantic HTML and Use It So, first thing: Learn semantic HTML. But what does it mean? Semantic HTML, or semantic markup, describes its meaning to the browser and developer in a human- and machine-readable way. So, with semantic elements, a human will know what the HTML element is about, and the browser knows what it should render and how it should behave when a user interacts with it. Here's an example: <button onClick={...}>I'm an honest button</button> That button uses a semantic button-element. When it does so, the browser knows what it should do when the user either clicks or activates it with a keyboard or other input device. Here's an example of a non-semantic "button": <div className="button" onClick={...}> I look like a button </div> So, this "button" made out of div looks like a button and even has the onClick-handler. So, wouldn't a human recognize it as a button? Well, yes and no. It depends on the human. You see, this "button" works only for mouse users. As div is not an interactive element by nature, it doesn't handle interaction the same way as, for example, a button-element. When using a semantic button-element, that onClick-event pro

## Accessible heading structure

DevFeed: [Accessible heading structure](<https://devfeed.tech/articles/accessible-heading-structure-9392.md>)

Original publisher: [Read original article](<https://a11yproject.com/posts/how-to-accessible-heading-structure/>)

Author: Rian Rietveld

Published: 2022-01-03T00:00:00Z

Content type: article

Language: en

Sources: [The A11Y Project](<https://devfeed.tech/sources/the-a11y-project.md>)

Topics: [HTML](<https://devfeed.tech/topics/html.md>), [html elements](<https://devfeed.tech/topics/html-elements.md>), [Search engine optimization (SEO)](<https://devfeed.tech/topics/seo.md>), [web-standards](<https://devfeed.tech/topics/web-standards.md>), [Content Management System](<https://devfeed.tech/topics/cms.md>)

Tags: [best-practices](<https://devfeed.tech/tags/best-practices.md>), [html](<https://devfeed.tech/tags/html.md>), [html-elements](<https://devfeed.tech/tags/html-elements.md>), [seo](<https://devfeed.tech/tags/seo.md>), [web](<https://devfeed.tech/tags/web.md>)

### AI overview

This article explains how to create accessible, semantic heading structures in HTML. It recommends using one unique h1 for the page topic, choosing heading levels hierarchically to describe the content that follows, and avoiding headings used only for visual styling. It also discusses common mistakes and the relationship between heading structure, screen reader navigation, and SEO.

### Source excerpt

Headings are the backbone of the content of a page. A visitor should be able to scan the webpage using headings to get a good impression of its content. Heading levels have meaning, especially for screen reader users and search engines. That means one unique first level heading per page, with the other headings representing the page content similar to the index of a book: easily scannable and semantic. Write well-structured headings, because what is good for your reader, is also good for your SEO. Headings in HTML Headings are HTML elements. The main heading, h1, is level 1. The other levels are h2 up to h6. The HTML Living Standard states on headings: A heading can be used where heading content is expected. Heading content defines the header of a section (whether explicitly marked up using sectioning content elements, or implied by the heading content itself). The HTML Living Standard, The h1, h2, h3, h4, h5, and h6 elements In short: use a heading when the content or the page structure requires it. Best practices summarized Use one unique h1 per page that describes what that page is about. That h1 preferably starts just above the main content. Use headings to describe the content below. Do not use an HTML heading just to make the text appear bigger or stand out. Use heading levels like the index of a book: hierarchical. Do not choose a heading by its size, but by its level in the context of the content. Do not skip a heading level from the top down. Common mistakes: Using a h2 heading for quotes because of its nice big font size. Using a h4 heading for the first paragraph of the text because it's just the size of bold text you need. Exclusively using h2 headings on a web page because all headings are the same size in the designs. Using multiple h1 headings on a web page. Omitting headings because the design clearly indicates the start of a new section. Leaving headings empty (usually a CMS glitch). What does hierarchical mean? Hierarchical means arranged in order

## Starting a design with accessibility

DevFeed: [Starting a design with accessibility](<https://devfeed.tech/articles/starting-a-design-with-accessibility-9414.md>)

Original publisher: [Read original article](<https://a11yproject.com/posts/starting-a-design-with-accessibility/>)

Author: Steve Barnett

Published: 2021-08-25T00:00:00Z

Content type: tutorial

Language: en

Sources: [The A11Y Project](<https://devfeed.tech/sources/the-a11y-project.md>)

Topics: [Accessibility](<https://devfeed.tech/topics/accessibility.md>), [HTML](<https://devfeed.tech/topics/html.md>), [alt text](<https://devfeed.tech/topics/alt-text.md>), [html elements](<https://devfeed.tech/topics/html-elements.md>), [Figma](<https://devfeed.tech/topics/figma.md>), [Sketch](<https://devfeed.tech/topics/sketch.md>)

Tags: [accessibility](<https://devfeed.tech/tags/accessibility.md>), [alt-text](<https://devfeed.tech/tags/alt-text.md>), [html](<https://devfeed.tech/tags/html.md>), [html-elements](<https://devfeed.tech/tags/html-elements.md>), [presentation](<https://devfeed.tech/tags/presentation.md>)

### AI overview

This article explains how to begin a design with accessibility in mind. It recommends creating a text-only design first to clarify content, structure, reading order, focus order, image information, link and button text, and form labels, followed by an HTML-only design using semantic elements before adding CSS or layout.

### Source excerpt

Designing with accessibility in mind from the start is even better than reviewing a design for accessibility. It helps us consider the wide range of people who use our products and services. Here are three things we can do to start a design with accessibility. Do a text-only design Doing a text-only design to helps us clarify the order and content of a page. What to do We can write out the design in text before opening up our favorite design tool (like Sketch or Figma or Adobe XD). Start by making a numbered list with pen and paper, or in a text editor. Write out the: Section headings, Content and function of each image, Text of each link, Text of each button, and Name of each form element. Why to do it Writing the content in a numbered list lets us be clear on: The source order of elements in the HTML. This is the order that a screen reader will read the page in. The hierarchy of elements on the page. This helps us make choices about layouts on different screen sizes. The focus order of the page. This helps us make sure it's logical and meaningful. Writing headings lets us divide the page up into logical sections. Screen reader users often use headings as a way of navigating around a page. Writing the text of images means we'll already have alt text (or something that's a good start on it). It helps us be clear on what information (if any) the image is conveying. Writing the text for links highlights why "Click here" isn't helpful link text. Link text should describe where the person goes when they follow the link. Writing the text for buttons highlights why "Submit" usually isn't helpful button text. Button text should describe what happens when the person presses the button. Writing the names of form elements forces us to think of good labels. It forces us to think about the clearest name for each element. Do an HTML-only design Doing an HTML-only design helps us clarify the order and content of a page. It also helps us clarify the single function of each interac

## Accessibility and SEO

DevFeed: [Accessibility and SEO](<https://devfeed.tech/articles/accessibility-and-seo-9365.md>)

Original publisher: [Read original article](<https://a11yproject.com/posts/accessibility-seo/>)

Author: Cooper Hollmaier

Published: 2021-07-01T00:00:00Z

Content type: article

Language: en

Sources: [The A11Y Project](<https://devfeed.tech/sources/the-a11y-project.md>)

Topics: [Accessibility](<https://devfeed.tech/topics/accessibility.md>), [Search engine optimization (SEO)](<https://devfeed.tech/topics/seo.md>), [HTML](<https://devfeed.tech/topics/html.md>), [html elements](<https://devfeed.tech/topics/html-elements.md>), [Google](<https://devfeed.tech/topics/google.md>), [Web](<https://devfeed.tech/topics/web.md>)

Tags: [accessibility](<https://devfeed.tech/tags/accessibility.md>), [content](<https://devfeed.tech/tags/content.md>), [google](<https://devfeed.tech/tags/google.md>), [html](<https://devfeed.tech/tags/html.md>), [html-elements](<https://devfeed.tech/tags/html-elements.md>), [links](<https://devfeed.tech/tags/links.md>), [search](<https://devfeed.tech/tags/search.md>), [seo](<https://devfeed.tech/tags/seo.md>), [web](<https://devfeed.tech/tags/web.md>)

### AI overview

This article explains that accessibility and search engine optimization often benefit from the same people-centered practices. It discusses meaningful section headings, page structure, HTML headings, and descriptive anchor text as ways to improve navigation for people while helping search engines understand and discover content.

### Source excerpt

Search engine optimization and accessibility have a lot more in common than you would think. Many of the same practices that we use to enable everyone to enjoy our digital experiences also open the doors for search engines. The intersection of people and search engines Search engine optimization often gets a bad reputation. In the early years, marketers were adding blocks of keywords into pages by the truck load. Getting to the top of the results by any means necessary was the game. Companies focused on publishing content that was machine-first, not people-first. The Search Engine Optimization (SEO) industry has since evolved. Marketers who choose to build for people over profit, are those that gain increased visibility online. Catering to bots and algorithm changes, by contrast, is often a game of whack-a-mole and traffic gains are short lived. Below, we will examine some of the ways accessibility and SEO teams can work together towards a future where everyone wins. Headings Search engines crawl through an endless sea of webpages everyday. Assembling information into search results would be impossible without some semblance of structure. This is where section headings come into play. When implemented to provide meaning rather than styling, headings create an easy way to scan and navigate a document for all people. <!-- Meh --> <strong>Animals</strong> <p>Monkeys, Lions, Bears</p> <!-- Better --> <h1>Animals</h1> <p>Monkey, lions, and bears are all examples of animals.</p> <h2>Monkeys</h2> <p>Monkeys are primarily found in tropical rain forests.</p> <h2>Lions</h2> <p>All wild lions live on the African continent, with the exception of a small population in western India.</p> <h2>Bears</h2> <p>Species of bears exist almost everywhere in the world.</p> Properly implemented HTML section headings help search engines, too. To determine if a page is relevant to a person's search, Google has to know about the contents of a page. If a page title isn't present in the code, se

## An in-depth guide to ARIA roles

DevFeed: [An in-depth guide to ARIA roles](<https://devfeed.tech/articles/an-in-depth-guide-to-aria-roles-9369.md>)

Original publisher: [Read original article](<https://a11yproject.com/posts/an-indepth-guide-to-aria-roles/>)

Author: Duncan Jimbo

Published: 2020-08-20T00:00:00Z

Content type: tutorial

Language: en

Sources: [The A11Y Project](<https://devfeed.tech/sources/the-a11y-project.md>)

Topics: [aria](<https://devfeed.tech/topics/aria.md>), [HTML](<https://devfeed.tech/topics/html.md>), [browser](<https://devfeed.tech/topics/browser.md>), [Web Development](<https://devfeed.tech/topics/web-development.md>)

Tags: [aria](<https://devfeed.tech/tags/aria.md>), [article](<https://devfeed.tech/tags/article.md>), [browser](<https://devfeed.tech/tags/browser.md>), [developers](<https://devfeed.tech/tags/developers.md>), [guide](<https://devfeed.tech/tags/guide.md>), [html](<https://devfeed.tech/tags/html.md>), [html-elements](<https://devfeed.tech/tags/html-elements.md>)

### AI overview

This guide explains ARIA roles, their six categories, and how they supplement HTML semantics when native elements are unavailable or insufficiently supported. It covers usage guidance, document structure roles, and landmark roles, with attention to browser and assistive technology support.

### Source excerpt

The ARIA specification is divided into categories of attributes, one of which is Roles, and the other being States & Properties. ARIA roles, which are covered in this article, are generally used to describe elements: that may not exist within HTML, which may not have full cross-browser support, which may have implementation gaps in screen readers and other assistive technologies. For instance, ARIA roles can be useful in situations where native HTML semantics are not understood in legacy user agents (e.g., browsers). Usage ARIA roles are added to elements using the role="<ROLE_TYPE>" attribute, where ROLE_TYPE represents the specific role being added. Once an ARIA role is set on an element, it should not be changed, regardless of the state of the element. In some cases, roles have to be paired with the appropriate ARIA state or property. However, this article's examples have reduced markup to limit the scope to just ARIA roles. ARIA roles are broken down into six categories: Abstract Roles Document Structure Roles Landmark Roles Live Region Roles Widget Roles Window Roles Abstract roles Abstract roles are only intended for use by browsers to help organize and streamline a document. They should not be used by developers writing HTML markup. Doing so will not result in any meaningful information being conveyed to assistive technologies or to users. Document Structure roles Document roles are used to provide a structural description for a section of content. A majority of the available roles in this category resemble available semantic HTML tags and it is recommended to only use them when an appropriate native tag is not available. The roles in this category are also not typically interactive in nature. However, they may be used to contain other roles that are interactive. The following examples of toolbar and tooltip roles, serve as good examples of when to use Document Structure roles to provide information to assistive technologies when the equivalent native HTML ta

## A couple of Jekyll updates

DevFeed: [A couple of Jekyll updates](<https://devfeed.tech/articles/a-couple-of-jekyll-updates-35135.md>)

Original publisher: [Read original article](<http://www.practicallyefficient.com/2017/07/02/a-couple-of-jekyll-updates.html>)

Author: Eddie Smith

Published: 2017-07-02T00:00:00Z

Content type: tutorial

Language: en

Sources: [Eddie Smith](<https://devfeed.tech/sources/eddie-smith.md>)

Topics: [Jekyll](<https://devfeed.tech/topics/jekyll.md>), [Markdown](<https://devfeed.tech/topics/markdown.md>), [CSS](<https://devfeed.tech/topics/css.md>), [YAML](<https://devfeed.tech/topics/yaml.md>), [HTML](<https://devfeed.tech/topics/html.md>), [LaTeX](<https://devfeed.tech/topics/latex.md>)

Tags: [css](<https://devfeed.tech/tags/css.md>), [html-elements](<https://devfeed.tech/tags/html-elements.md>), [jekyll](<https://devfeed.tech/tags/jekyll.md>), [latex](<https://devfeed.tech/tags/latex.md>), [markdown](<https://devfeed.tech/tags/markdown.md>), [yaml](<https://devfeed.tech/tags/yaml.md>)

### AI overview

A personal update on a Jekyll site that adds image captions with CSS and Markdown, and integrates MathJax selectively through YAML front matter while retaining the kramdown converter.

### Source excerpt

Since moving to Jekyll last year, I've done relatively little to tweak the inner workings of this site. After all, one of the most appealing things about having a static site is that it doesn't need to have a lot of moving parts. It just works. But today I finally got around to a couple of housekeeping items that have been on my list: image captions and MathJax. Image captions For image captions, I settled on a beautifully simple solution posted by Andrew Wei on Stack Overflow:  *image_caption* This takes advantage of the fact that you can create CSS for combinations of HTML elements. In this case, I can use img + em { display: block; text-align: center;} to target the *image_caption* text only and center it under images, which are also centered on this site by default. It works perfectly, and this isn't even Jekyll-specific. Anyone publishing in Markdown could do this. Agreed. Jekyll + MathJax Adding MathJax took a little more time, but not much. It was worth it just to remind me of the brilliance of Jekyll's architecture. Even though the Jekyll site mentions MathJax, it doesn't say enough to be of immediate use. It basically points to a blog post that entails switching from the default kramdown Markdown converter to redcarpet. Given that I'm happy with kramdown and not in the mood to backtest a bunch of blog posts with a different converter, I wanted to stick with kramdown. A series of subsequent web searches lead me to a Github issue thread for a Jekyll theme that I'm not even using, but I found a really efficient implementation of MathJax there by user "mmistakes," who suggested adding a mathjax variable in each page's YAML front matter that could be set to true on a post by post basis. The elegance of this solution is that the MathJax script will only be written into the HTML of posts that actually have MathJax in them. This seemed super appealing to me because it meant that I didn't have to worry about MathJax being triggered by some accident

## When and How to Use XHP Categories

DevFeed: [When and How to Use XHP Categories](<https://devfeed.tech/articles/when-and-how-to-use-xhp-categories-22038.md>)

Original publisher: [Read original article](<https://codebeforethehorse.tumblr.com/post/65461659692>)

Author: Codebeforethehorse

Published: 2013-10-29T21:23:00Z

Content type: tutorial

Language: en

Sources: [Stefan Parker](<https://devfeed.tech/sources/stefan-parker.md>)

Topics: [html elements](<https://devfeed.tech/topics/html-elements.md>), [HTML](<https://devfeed.tech/topics/html.md>), [HTML5](<https://devfeed.tech/topics/html5.md>), [ui](<https://devfeed.tech/topics/ui.md>), [Web Development](<https://devfeed.tech/topics/web-development.md>)

Tags: [how-to](<https://devfeed.tech/tags/how-to.md>), [html-elements](<https://devfeed.tech/tags/html-elements.md>), [html5](<https://devfeed.tech/tags/html5.md>), [opinion](<https://devfeed.tech/tags/opinion.md>), [ui](<https://devfeed.tech/tags/ui.md>), [xhp](<https://devfeed.tech/tags/xhp.md>)

### AI overview

The article explains how XHP validates child elements in two passes: custom components are rendered into HTML primitives before the resulting HTML tree is validated. It recommends grouping custom XHP elements by the type of root node returned from render(), allowing related abstractions to remain composable while preserving child validation.

### Source excerpt

I remember when we first added the children keyword to XHP. We had the problem that validating them was really cumbersome. Nearly every element was valid inside a <div> but not all (for instance <meta>). Listing out every valid child wasn't very elegant and certainly would cause problems for custom XHP components. Fortunately, the HTML spec categorized elements just for this purpose. Grouping elements into "block" or "inline" categories made validation far simpler. But if you've used XHP you might be wondering, "Why have I never needed to define my elements as inline or block before?" Well, the answer lies in how XHP renders an element tree. First it will render down all your custom elements into their eventual HTML primitives, then it will render the entire HTML primitive tree into a text string. The key here is that there are actually two passes, meaning XHP validates children in two sets: your elements first and then core HTML elements second. When you put a custom component inside of a <span> element, you don't need to give it a category of %phrase (the HTML5 equivalent of %inline). When XHP renders the tree it will wait on validating the children of the root <span> until its children are HTML elements. class :ui:hello-world extends :x:element { protected function render() { return <b>Hello World!</b>; } } $root = <span> <ui:hello-world /> </span>; So when you render $root, XHP will first render the <ui:hello-world> instance (which will produce the following node tree: <span><b>Hello World!</b></span>). Then it will render (and validate) the <span> and <b> elements. If we returned a <div> element from the :ui:hello-world::render method, then the validation would fail. So since we can use categories with free reign in our custom components, what pattern should we use? HTML groups elements by purpose, but it is my personal opinion that the best way to use categories is to group XHP elements by the type of their returned root node from render(). Let's look at an ex

## Using captions with HTML's video element

DevFeed: [Using captions with HTML's video element](<https://devfeed.tech/articles/using-captions-with-html-s-video-element-9421.md>)

Original publisher: [Read original article](<https://a11yproject.com/posts/using-caption-services-with-html5-video/>)

Author: Nat Tarnoff

Published: 2013-07-17T00:00:00Z

Content type: article

Language: en

Sources: [The A11Y Project](<https://devfeed.tech/sources/the-a11y-project.md>)

Topics: [HTML](<https://devfeed.tech/topics/html.md>), [Document Object Model (DOM)](<https://devfeed.tech/topics/dom.md>), [Web Development](<https://devfeed.tech/topics/web-development.md>), [XML](<https://devfeed.tech/topics/xml.md>), [Frameworks](<https://devfeed.tech/topics/frameworks.md>)

Tags: [content](<https://devfeed.tech/tags/content.md>), [flash](<https://devfeed.tech/tags/flash.md>), [html](<https://devfeed.tech/tags/html.md>), [html-elements](<https://devfeed.tech/tags/html-elements.md>), [transcripts](<https://devfeed.tech/tags/transcripts.md>), [video](<https://devfeed.tech/tags/video.md>), [video-js](<https://devfeed.tech/tags/video-js.md>), [web](<https://devfeed.tech/tags/web.md>)

### AI overview

This article explains how to make HTML5 video more accessible by adding captions and transcripts. It covers using the video element's track element, the WebVTT caption format, alternative formats such as TTML, and YouTube's auto-generated captions as a transcription aid.

### Source excerpt

One of the great things about the internet is the ability to share video. With HTML we can now use video without the use of Flash. This makes video more accessible as the controls are located in the DOM. However, to do accessible video right, you need to include captions and transcripts. In addition to making video accessible to those with hearing issues, having a transcript on the page can provide you localization of a video not always available in the local language. Transcripts also give all users an alternate way to access the information presented in a video. Additionally, with a transcript on your page, you may increase your search engine rankings by making your content easily indexed by search engine crawl spiders. So how do we pull off putting captions into a video after the video has been produced? Fortunately, the video element has a solution for us. We have to provide a transcript file as a track element after the video source files. <video class="span12 readable" poster="your-video-poster.jpg" controls title="My Movie"> <source src="your-video.m4v" type='video/mp4; codecs="avc1.42E01E, mp4a.40.2"' /> <source src="your-video.ogg" type='application/ogg' /> <source src="your-video.webm" type='video/webm' /> <track src="your-video-transcript.vtt" label="English Captions" kind="subtitles" srclang="en-us" default /> </video> Many frameworks built on top of the video element make it even simpler to add in captions, like Video.js. But what do these track files look like? WebVTT One of the most commonly-used caption formats is Web Video Text Tracks (WebVTT), which is saved as a file with the extension .vtt. This is a specially formatted text document. It contains each of the cues numbered, followed by the start time & end time and finally the text. It is recommended to include in the text the name of the person talking. Some styling can be included in the text via basic HTML elements like i or b. We start it by declaring it a WEBVTT file. WEBVTT 1 00:00:09.000 --

## Use role='application'

DevFeed: [Use role='application'](<https://devfeed.tech/articles/use-role-application-9394.md>)

Original publisher: [Read original article](<https://a11yproject.com/posts/how-to-use-application-role/>)

Author: Dennis Gaebel

Published: 2013-02-09T00:00:00Z

Content type: article

Language: en

Sources: [The A11Y Project](<https://devfeed.tech/sources/the-a11y-project.md>)

Topics: [aria](<https://devfeed.tech/topics/aria.md>), [web-standards](<https://devfeed.tech/topics/web-standards.md>), [HTML](<https://devfeed.tech/topics/html.md>), [html elements](<https://devfeed.tech/topics/html-elements.md>), [Forms](<https://devfeed.tech/topics/forms.md>), [browser](<https://devfeed.tech/topics/browser.md>)

Tags: [aria](<https://devfeed.tech/tags/aria.md>), [browser](<https://devfeed.tech/tags/browser.md>), [forms](<https://devfeed.tech/tags/forms.md>), [html](<https://devfeed.tech/tags/html.md>), [html-elements](<https://devfeed.tech/tags/html-elements.md>), [user-interface](<https://devfeed.tech/tags/user-interface.md>), [web](<https://devfeed.tech/tags/web.md>)

### AI overview

The article explains how to use the WAI-ARIA role="application" carefully. It recommends applying the role sparingly, mainly to individual widgets or pages that do not resemble traditional documents, and relying on browser and assistive technology behavior for standard HTML controls and dynamic widgets when possible.

### Source excerpt

Never use role="application" on a widely containing element such as <body> if your page consists mostly of traditional widgets or page elements such as links that the user does not have to interact with in focus mode. Using role="application" unnecessarily can cause huge headaches for any assistive technology user trying to use your site/application. Only put it on the <body> element if your page consists solely of a widget or set of widgets that all need the focus mode[1] to be turned on. Do Use sparingly. If your page has no resemblance to a classic document in roughly over 90% of its content. Use clear labels within your application. Don't If a set of controls or user interface only contains these widgets that are all part of standard HTML[2] If your widget is dynamic such as a tree view, slider or table. Unless you take a great deal of care in ensuring that you've recreated a lot of native-ish custom navigation, it's almost always better to let the browser/assistive technology handle things. We only recommend using role='application' on a per-widget basis, and even then: very, very carefully. Allows the user to interact with forms and ARIA-enabled HTML elements. ↩︎ Standard HTML refers to: text, password, search, tel and other newer input type derivates, textarea, checkbox, button, radio button (usually inside a fieldset/legend element wrapper), select & option(s), links, paragraphs, headings, and other things that are classic/native to documents on the web. ↩︎

## Data- & Aria- Attribute Support Added to XHP

DevFeed: [Data- & Aria- Attribute Support Added to XHP](<https://devfeed.tech/articles/data-aria-attribute-support-added-to-xhp-22034.md>)

Original publisher: [Read original article](<https://codebeforethehorse.tumblr.com/post/41920380130>)

Author: Codebeforethehorse

Published: 2013-01-31T03:47:00Z

Content type: release

Language: en

Sources: [Stefan Parker](<https://devfeed.tech/sources/stefan-parker.md>)

Topics: [aria](<https://devfeed.tech/topics/aria.md>), [html elements](<https://devfeed.tech/topics/html-elements.md>), [ui](<https://devfeed.tech/topics/ui.md>)

Tags: [aria](<https://devfeed.tech/tags/aria.md>), [download](<https://devfeed.tech/tags/download.md>), [framework](<https://devfeed.tech/tags/framework.md>), [html-elements](<https://devfeed.tech/tags/html-elements.md>), [source](<https://devfeed.tech/tags/source.md>), [xhp](<https://devfeed.tech/tags/xhp.md>)

### AI overview

The article announces data- and aria-attribute support in XHP. The support is implemented in :x:composable-element, allowing these attributes on XHP elements; HTML elements render them, while custom extensions do not use them by default.

### Source excerpt

Last night I added data- and aria- attribute support into XHP. I baked it into :x:composable-element directly instead of relying on previous methods which only added it to :xhp:html-element. I did this for a few reasons. First, I didn't like the idea of getAttribute() and setAttribute() not being final within :x:primitive. Secondly, if you want to build a UI framework on top of :x:element that forwards attributes, you'd need to un-final getAttribute() and setAttribute() in :x:element too, and duplicate all the logic in :xhp:html-element into your UI framework. No, I feel it's much better to have the slightly nuanced behavior of always allowing data- and aria- attributes on XHP, even if they won't do anything on custom :x:element extensions by default (HTML elements render them just fine). You can download the latest source at: https://github.com/facebook/xhp.

## Future-proofing your accessibility efforts

DevFeed: [Future-proofing your accessibility efforts](<https://devfeed.tech/articles/future-proofing-your-accessibility-efforts-9384.md>)

Original publisher: [Read original article](<https://a11yproject.com/posts/future-proof-your-accessibility/>)

Author: Thomas Sjögren

Published: 2013-01-22T00:00:00Z

Content type: article

Language: en

Sources: [The A11Y Project](<https://devfeed.tech/sources/the-a11y-project.md>)

Topics: [Accessibility](<https://devfeed.tech/topics/accessibility.md>), [Web Content Accessibility Guidelines](<https://devfeed.tech/topics/web-content-accessibility-guidelines.md>), [HTML](<https://devfeed.tech/topics/html.md>), [html elements](<https://devfeed.tech/topics/html-elements.md>), [browsers](<https://devfeed.tech/topics/browsers.md>), [Web Development](<https://devfeed.tech/topics/web-development.md>)

Tags: [accessibility](<https://devfeed.tech/tags/accessibility.md>), [browsers](<https://devfeed.tech/tags/browsers.md>), [html](<https://devfeed.tech/tags/html.md>), [html-elements](<https://devfeed.tech/tags/html-elements.md>), [tech-debt](<https://devfeed.tech/tags/tech-debt.md>), [web-content-accessibility-guidelines](<https://devfeed.tech/tags/web-content-accessibility-guidelines.md>)

### AI overview

This article explains how semantic HTML and two WCAG rules--Parsing and Name, Role, Value--can make accessibility efforts more durable. It offers practical guidance on valid markup, unique IDs, correct element nesting, and accessible custom controls, while highlighting benefits for browsers, assistive technologies, and long-term technical debt.

### Source excerpt

Your future self, coworkers, and most importantly customers and clients will thank you for developing with accessibility in mind. Tech debt goes down when accessibility goes up The best way to future proof your accessibility efforts is to ensure websites and applications are built with a foundation in proper HTML semantics. We can help ensure we are future-proofing our project by following two rules from Web Content Accessibility Guidelines (WCAG): Parsing and Name, Role, Value. Following these rules has the bonus value of better supporting current and future browsers and other user agents, while additionally ensuring assistive technologies (AT) such as screen readers will be more likely to correctly interpret the content of our projects. Breaking down the rules Let's define the WCAG rules and look at some quick tips to help follow them. 4.1.1 Parsing Following this rule helps ensure that browsers and AT will be able to correctly interpret your web interface without complications from poorly-structured markup. The W3C Nu HTML Checker can help you locate errors in your source or rendered markup. Any reported validation can be corrected, which will help decrease the likelihood of ATs incorrectly parsing your website. Follow the official HTML specifications for guidance on writing correct markup. Some quick tips: make sure to close open tags (<div class="a-class">...</div>), use unique ids, and don't incorrectly nest HTML elements. 4.1.2 Name, role, value This rule is related to the components and controls that make up the web interface. It helps to ensure components can have their name and role programmatically determined, and that their states, properties, and values can be set by the individual interacting with them. All standard HTML controls already meet these rules by default. The guideline is primarily aimed at developers that heavily redesign or modify the functionality of standard HTML controls, or design and/or script their own interface components and contro

## ARIA Landmark roles and HTML5 implicit mapping

DevFeed: [ARIA Landmark roles and HTML5 implicit mapping](<https://devfeed.tech/articles/aria-landmark-roles-and-html5-implicit-mapping-9372.md>)

Original publisher: [Read original article](<https://a11yproject.com/posts/aria-landmark-roles/>)

Author: Erik Runyon

Published: 2013-01-14T00:00:00Z

Content type: article

Language: en

Sources: [The A11Y Project](<https://devfeed.tech/sources/the-a11y-project.md>)

Topics: [aria](<https://devfeed.tech/topics/aria.md>), [Accessibility](<https://devfeed.tech/topics/accessibility.md>), [HTML5](<https://devfeed.tech/topics/html5.md>), [html elements](<https://devfeed.tech/topics/html-elements.md>)

Tags: [accessibility](<https://devfeed.tech/tags/accessibility.md>), [aria](<https://devfeed.tech/tags/aria.md>), [browsers](<https://devfeed.tech/tags/browsers.md>), [html](<https://devfeed.tech/tags/html.md>), [html-elements](<https://devfeed.tech/tags/html-elements.md>), [html5](<https://devfeed.tech/tags/html5.md>), [internet-explorer](<https://devfeed.tech/tags/internet-explorer.md>), [post](<https://devfeed.tech/tags/post.md>), [support](<https://devfeed.tech/tags/support.md>)

### AI overview

This article explains how ARIA landmark roles help assistive technology users orient themselves and navigate websites or applications. It covers common landmarks such as banner, search, main, navigation, and contentinfo, and explains how HTML5 elements can provide many of these landmarks implicitly.

### Source excerpt

ARIA Landmark Roles can be helpful to assistive device users, as they can be used to orient a user to, and easily navigate, your website or application. For a quick video demonstration, check out "How ARIA landmark roles help screen reader users", by Léonie Watson. Landmark quick reference The following are common landmark roles that tend to be useful on many pages: banner Typically the primary "header" of your page, containing the name of the site/application along with other globally available content. It MUST be scoped to the body element, and not within another sectioning element, or the main of the document. search Use on the primary search form. Often, but not always, found within a banner. If you have multiple search landmarks in a document it would be good to provide them with unique accessible names to indicate how they differ. main Designates the primary content area of the current document. Only one main landmark should be exposed to users at a time. navigation Used to promote an area as a navigation. Combine with a unique aria-label to provide context of the navigation's purpose. e.g. <nav aria-label="primary">. contentinfo Typically the "footer" of your page that contains information about the parent document such as copyrights and links to privacy statements. Implementing landmarks in your documents is a straightforward process. Simply add the role attribute referencing the appropriate landmark value. For example: <div role="contentinfo"> ... </div> HTML5 implicit mappings of Landmark roles Before you start adding ARIA roles to your HTML elements, you should be aware that many of these landmarks will be natively conveyed by proper HTML usage. For example, the following markup snippet will produce a warning in modern HTML and accessibility automated checkers: <header role="banner" class="site-header"> ... </header> The following table outlines the different ARIA landmarks, and the HTML5 element they are associated with: Landmark Role HTML Element banner

## The Difference Between :x:element and :x:primitive

DevFeed: [The Difference Between :x:element and :x:primitive](<https://devfeed.tech/articles/the-difference-between-x-element-and-x-primitive-22031.md>)

Original publisher: [Read original article](<https://codebeforethehorse.tumblr.com/post/35419887698>)

Author: Codebeforethehorse

Published: 2012-11-10T18:16:00Z

Content type: tutorial

Language: en

Sources: [Stefan Parker](<https://devfeed.tech/sources/stefan-parker.md>)

Topics: [XSS](<https://devfeed.tech/topics/xss.md>), [Sanitization](<https://devfeed.tech/topics/sanitization.md>), [HTML](<https://devfeed.tech/topics/html.md>), [JSON](<https://devfeed.tech/topics/json.md>), [html elements](<https://devfeed.tech/topics/html-elements.md>), [Ajax](<https://devfeed.tech/topics/ajax.md>)

Tags: [foreach](<https://devfeed.tech/tags/foreach.md>), [function](<https://devfeed.tech/tags/function.md>), [html](<https://devfeed.tech/tags/html.md>), [html-elements](<https://devfeed.tech/tags/html-elements.md>), [json](<https://devfeed.tech/tags/json.md>), [payload](<https://devfeed.tech/tags/payload.md>), [protection](<https://devfeed.tech/tags/protection.md>), [render](<https://devfeed.tech/tags/render.md>), [rest](<https://devfeed.tech/tags/rest.md>), [xhp](<https://devfeed.tech/tags/xhp.md>), [xss](<https://devfeed.tech/tags/xss.md>)

### AI overview

This article explains when to use :x:element versus :x:primitive in XHP. It recommends :x:element for most cases because its render() method produces more XHP and supports recursive rendering, while :x:primitive ultimately stringifies the result. It identifies custom HTML nodes and non-HTML output such as JSON AJAX responses as the main reasons to use :x:primitive.

### Source excerpt

I was recently asked to clarify the differences between :x:element and :x:primitive, and when to use each one. It's actually pretty simple; the basic rule of thumb is this: always use :x:element. If you're only doing simple things in XHP you can stop reading now, but for the rest of you I'll get into the rare instances where you might use :x:primitive. First, the main difference. :x:element implements the render() method, which returns more XHP while :x:primitive implements to stringify() method, which returns a string. When you echo XHP to the page, it recursively calls render() on itself until it returns an :x:primitive. It will continue to do this to any children of an :x:primitive as well. Once the entire tree is just :x:primitives (usually meaning just HTML nodes) it stringify()s it. So why the difference? The big reason was that we can put XSS protection in all HTML elements and so long as you just return HTML nodes you'll never have to worry about input sanitization again. There are two cases where you would want to create an :x:primitive though. The first being if you wanted to create a custom HTML node. Let's say you wanted to create a <foo> tag for your own purposes. All you would need to do is extend :xhp:html-element (which extends :x:primitive) and define its tag name. class :foo extends :xhp:html-element { protected $tagname = 'foo'; } Pretty simple. You could define custom attributes and children restrictions too if you so desired. The other reason you would extend :x:primitive is if you wanted to return something other than HTML. Consider an AJAX response that returns a JSON object. You might construct an object that behaves like this: class :ajax:response extends :x:primitive { attribute array payload; attribute array errors; protected function stringify() { $html = ''; foreach ($this->getChildren() as $child) { $html .= :x:base::renderChild($child); } $response = array( 'payload' => $this->getAttribute('payload'), 'errors' => $this->getAttribute('e

## Semantics in practice and mapping semantic value to its consumers

DevFeed: [Semantics in practice and mapping semantic value to its consumers](<https://devfeed.tech/articles/semantics-in-practice-and-mapping-semantic-value-to-its-consumers-21665.md>)

Original publisher: [Read original article](<https://paulirish.com/2011/semantics/>)

Author: Paul Irish

Published: 2011-11-14T18:25:00Z

Content type: article

Language: en

Sources: [Paul Irish](<https://devfeed.tech/sources/paul-irish.md>)

Topics: [Accessibility](<https://devfeed.tech/topics/accessibility.md>), [HTML5 and CSS3 tricks](<https://devfeed.tech/topics/html5-and-css3-tricks.md>), [aria](<https://devfeed.tech/topics/aria.md>), [HTML](<https://devfeed.tech/topics/html.md>), [web-standards](<https://devfeed.tech/topics/web-standards.md>)

Tags: [accessibility](<https://devfeed.tech/tags/accessibility.md>), [aria](<https://devfeed.tech/tags/aria.md>), [browsers](<https://devfeed.tech/tags/browsers.md>), [html](<https://devfeed.tech/tags/html.md>), [html-elements](<https://devfeed.tech/tags/html-elements.md>), [html5](<https://devfeed.tech/tags/html5.md>), [implementation](<https://devfeed.tech/tags/implementation.md>)

### AI overview

The article argues that practical accessibility should take priority over intricate or unstable HTML semantics. It discusses HTML5 elements, document outlining, heading structure, screen reader behavior, ARIA, browser implementation, and assistive technology accessibility APIs.

### Source excerpt

Divya Manian kicked off a good bout of discussion of HTML semantics with her post Our pointless pursuit of semantic value. It called into question the amount of time we spend on identifying the Right and Best ways of marking up our content while highlighting details of some of the consumers of semantics like assistive technology (AT). Jeremy Keith responded in Pursing Semantic Value. I wanted to chime in on Jeremy's post so, I've published below my comment from the original post: Thanks Jeremy for raising a practical example. This discussion is a tough one as much of HTML5 has clear semantics (nav/header/footer), but then parts have underdeveloped semantic meaning or add confusion to authors. Jeremy's gist is a great example, in fact, of a poor time investment in semantics. It ascribes value to the new method of document outlining, which recently sees different styling for h1's depending on section nesting. Recent browsers do indeed style the h1's different; but if you actually structure your document as such, you do it to the detriment of your screenreader users: they will either get these h1's all as top level headlines or a mishmash of heading nesting levels that don't match any expected behavior (As an aside, this is completely unrelated but if anyone's curious what CSS it takes to make that new h1 styling work across browsers... feast your eyes on this beauty) Additionally, <hgroup> is on the chopping block and is not supported by JAWS. Suffice it to say, Now is not a smart time to invest your time understanding the unwieldy document outlining algorithm. Luke's comment digs in deeper to the messy semantic state of the outlining algorithm. semantics are hard...let's go shopping and CREATE EPIC SHIT... -- patrick h. lauke (@patrick_h_lauke) November 14, 2011 The practicalities of making accessible web content are messy, but important. The fact that we seem to spend more time on div vs article vs. section than on learning ARIA is a crime. (Furthermore, learning ARIA isn'