# html elements

HTML elements are defined as part of the HTML standard, with specified semantics, DOM representation, constructors, attributes, and content models.

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

## CSS-only glitch effect

DevFeed: [CSS-only glitch effect](<https://devfeed.tech/articles/css-only-glitch-effect-37255.md>)

Original publisher: [Read original article](<https://muffinman.io/blog/css-image-glitch/>)

Author: Stanko

Published: 2025-04-03T00:00:00Z

Content type: tutorial

Language: en

Sources: [Stanko Tadić](<https://devfeed.tech/sources/stanko-tadic.md>)

Topics: [CSS](<https://devfeed.tech/topics/css.md>), [CSS animations](<https://devfeed.tech/topics/css-animations.md>), [HTML](<https://devfeed.tech/topics/html.md>), [html elements](<https://devfeed.tech/topics/html-elements.md>), [Code](<https://devfeed.tech/topics/code.md>)

Tags: [animation](<https://devfeed.tech/tags/animation.md>), [css](<https://devfeed.tech/tags/css.md>), [css-animations](<https://devfeed.tech/tags/css-animations.md>), [html](<https://devfeed.tech/tags/html.md>), [javascript](<https://devfeed.tech/tags/javascript.md>)

### AI overview

This tutorial explains how to create an image glitch effect using only HTML and CSS. It describes representing an image as vertically shifted strips, varying strip heights, displacing the strips, altering colors, and using closely spaced CSS keyframes to create abrupt movement. JavaScript is used only to generate the HTML and CSS, not in the final effect.

### Source excerpt

Let me show you how I created a CSS-only image glitch effect. I was working on the robot poet and wanted my robotic bard to glitch - because it felt fitting given the quality of poetry it generates. Here's the final result: The effect involves quite a bit of HTML and CSS but no JavaScript. I did use JavaScript to generate the HTML and CSS, but it is not used in the final version. To be clear, there's nothing wrong with using JavaScript for this kind of thing. I just saw it as a fun challenge to make a pure CSS version. The idea # In the words of Daft Punk: Slice It Move It Hue-Rotate It We'll have to slice the image into strips and randomly displace them while altering colors at the same time. Slice it # I wanted to use a single image without having to slice it manually. To achieve that, we need to create a bunch of divs. Each div represents one strip and has the image set as a background, but the image is shifted vertically. When stacked on top of each other, the divs look the same as the original image. To make the glitch effect more believable, we'll use a random height for each strip. We could do this by hand, but that would be tedious, so let's use code: const getStripHTML = (top: number, stripHeight: number): string => { const duration = random(5, 10); const name = `glitch-${duration}`; return ` <div class="strip" style="height: ${stripHeight}px; background-position: 0 -${top}px;" />`; }; const getGlitchHTML = (height: number): string[] => { let i = 0; const html: string[] = []; while (1) { const stripHeight = random(1, 6); if (i + stripHeight < height) { const strip = getStripHTML(i, stripHeight); html.push(strip); } else { // Last strip const strip = getStripHTML(i, height - i); html.push(strip); break; } i = i + stripHeight; } return html; }; Show codeHide code This gives us a list of divs with the image inside. When we render them all, we get the original image in a bunch of HTML elements we can manipulate individually. Toggle gap Now that we have our stri

## How to Override width and height HTML attributes with CSS

DevFeed: [How to Override width and height HTML attributes with CSS](<https://devfeed.tech/articles/how-to-override-width-and-height-html-attributes-with-css-37475.md>)

Original publisher: [Read original article](<https://davidwalsh.name/css-override-width-height>)

Author: David Walsh

Published: 2024-02-05T11:28:01Z

Content type: tutorial

Language: en

Sources: [David Walsh](<https://devfeed.tech/sources/david-walsh.md>)

Topics: [CSS](<https://devfeed.tech/topics/css.md>), [HTML](<https://devfeed.tech/topics/html.md>), [Responsive Design](<https://devfeed.tech/topics/responsive-design.md>), [html elements](<https://devfeed.tech/topics/html-elements.md>), [Web Development](<https://devfeed.tech/topics/web-development.md>)

Tags: [css](<https://devfeed.tech/tags/css.md>), [css-html5](<https://devfeed.tech/tags/css-html5.md>), [how-to](<https://devfeed.tech/tags/how-to.md>), [html](<https://devfeed.tech/tags/html.md>), [html5](<https://devfeed.tech/tags/html5.md>), [image](<https://devfeed.tech/tags/image.md>), [responsive-design](<https://devfeed.tech/tags/responsive-design.md>)

### AI overview

This tutorial explains how CSS can override HTML width and height attributes for images. It discusses preserving image dimensions for layout performance while using responsive styling to avoid distorted images.

### Source excerpt

One of the HTML elements that frequently comes into collision with CSS is the img element. As we learned in Request Metrics' Fixing Cumulative Layout Shift Problems on DavidWalshBlog article, providing image dimensions within the image tag will help to improve your website's score. But in a world where responsive design is king, we need [...] The post How to Override width and height HTML attributes with CSS appeared first on David Walsh Blog.

## 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

## 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

## 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

## 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