The Contact Address Element

A developer's guide to semantic contact information markup in HTML

What Is the Address Element?

The <address> HTML element indicates that the enclosed HTML provides contact information for a person, people, or organization. This semantic element communicates to browsers, search engines, and assistive technologies that the contained content represents contact details worthy of special handling.

The key distinction that separates <address> from other HTML elements is its semantic purpose. Unlike <div> or <span> which carry no inherent meaning, <address> communicates that the contained content represents contact information worthy of special handling. This semantic clarity helps screen reader users understand they are encountering contact details rather than ordinary text content.

Contact Information Types

  • Email addresses - using mailto: protocol
  • Phone numbers - using tel: protocol
  • Physical addresses - formatted mailing locations
  • Website URLs - related online resources
  • Social media handles - alternative contact channels
  • Geographic coordinates - precise location data

According to MDN Web Docs, modern implementations embrace a broad definition of "contact information" that extends well beyond traditional postal addresses.

Proper contact information markup also supports local SEO efforts, helping search engines understand business locations and contact details for improved visibility in geographic searches.

Proper Usage Contexts

Article-Level Contact Information

When placed within an <article> element, <address> provides contact information specifically for the author of that article. This context helps visitors understand exactly whose contact details they are viewing. A blog post might include the author's email address and personal website, allowing readers to reach out with questions or feedback directly related to that specific piece of content.

The scope of article-level address information should remain focused on the author. Including unrelated business addresses or general company information within an article-level address would confuse users about who they are actually contacting.

Page-Level Contact Information

When used in a footer or within <body> directly, <address> identifies contact information for the website or page owner. This represents the broader organizational context. Business websites typically place their main contact information here, including headquarters addresses, customer service phone numbers, and general inquiry email addresses.

Page-level address information should represent the organization or entity responsible for the entire page or website. For a business website, this might include the company's main office address, central phone line, and general contact email.

Footer Placement

The HTML specification recommends placing <address> within the <footer> of the current section when available. This convention aligns with user expectations--visitors commonly look to footers when seeking contact information. As documented by MDN Web Docs, the footer context also distinguishes contact information from primary page content, signaling its supplementary nature.

Professional web development ensures proper semantic HTML structure including correct address element implementation for better accessibility and search engine understanding.

Business Contact Information Example
1<address>2 Digital Thrive Inc.<br>3 123 Business Avenue, Suite 100<br>4 Toronto, ON M5V 2T6<br>5 Canada<br>6 <a href="mailto:[email protected]">[email protected]</a><br>7 <a href="tel:+14165550132">+1 (416) 555-0132</a>8</address>

What Address Should NOT Contain

Avoid Arbitrary Postal Addresses

The <address> element is NOT meant for arbitrary postal addresses. Property addresses in real estate listings, location data for objects, or addresses unrelated to contact purposes should not use this element. As noted by Suman's Accessibility Blog, the address must represent contact information relevant to the document or section--this distinction prevents misuse in contexts like real estate listings.

Prohibited Content

The HTML specification prohibits these elements within <address>:

  • Nested <address> elements
  • Heading content (<h1>-<h6>, <hgroup>)
  • Sectioning content (<article>, <aside>, <nav>, <section>)
  • <header> or <footer> elements

These restrictions ensure <address> remains focused purely on contact information without introducing nested document structures that would complicate accessibility tree interpretation.

Metadata Exclusions

Publication dates and temporal metadata should not appear within <address>. Use <time> elements for dates instead, maintaining semantic distinction between contact information and temporal metadata. This separation helps automated systems correctly interpret and process different types of document content.

As documented by MDN Web Docs, the specification explicitly states that <address> should not contain publication dates or similar metadata.

Accessibility Considerations

Screen Reader Behavior

The accessibility behavior of <address> elements varies across screen readers and browsers. According to Suman's Accessibility Blog, most screen readers do not currently provide special semantic announcements for <address> content, meaning users may not receive explicit indication they are encountering contact information.

VoiceOver Issue

VoiceOver on iPhone and Mac incorrectly announces <address> as "content info" rather than contact information. This bug has been documented in WebKit's issue tracker, though no fix has been implemented at the time of this writing.

ARIA Role Mapping

The HTML Accessibility API Mappings (HTML AAM) specification has evolved regarding <address> element role assignments. Earlier versions mapped the element to the contentinfo landmark role, which contributed to VoiceOver's incorrect announcements. Current specifications assign no implicit ARIA role to <address>, removing this mapping and reducing confusion potential.

Current Recommendations

Use <address> for semantic correctness while understanding its accessibility impact remains limited. The element provides value through well-structured contact information that works correctly with styling, copy-paste, and extraction tools. Despite inconsistent screen reader announcements, proper use contributes to overall document quality and semantic clarity.

For comprehensive accessibility implementation, consider AI-powered automation solutions that can help validate and test contact information accessibility across different devices and platforms.

Best Practices for Implementation

Include Contact Names

Always include the name of the person, people, or organization. This provides essential context for who can be reached.

Use Proper Protocols

Use `mailto:` for email addresses and `tel:` for phone numbers to enable one-click contacting on all devices.

Maintain Visual Distinction

Keep some visual distinction from regular text. Contact information should be recognizable as distinct content.

Keep It Relevant

Only include contact information relevant to the document's author or owner. Avoid unrelated data.

Frequently Asked Questions

Master Semantic HTML for Better User Experiences

Explore more HTML elements and accessibility best practices in our comprehensive UI/UX resources.