Wednesday, October 23, 2013

HTML 5 Semantics and Web Accessibility: Heading Structure

Has a designer or developer ever tried lecturing you about why you need to be using proper HTML semantics? If so, did your mind start to wander about 30 seconds into the lecture (is it starting to wander right now)? Do you read the HTML specification to help you fall asleep at night? As long as your site looks good and is maintainable, no user is ever going to know or care if your markup is semantically correct.

Actually, some users with disabilities will know if you're not, they depend on it, and probably can't use your site if you're not using clean, valid, and semantic HTML. Having valid semantic markup helps your site avoid many common accessibility issues. However, in some cases the HTML spec offers several different implementation options or is simply unclear. In these cases thinking in terms of accessibility can help provide direction.

HTML Headings as "Defined" by the Specification

The <h1> - <h6> heading tags are among the most useful and important HTML tags regarding semantics. They define the overall structure of the pages in your site. I hesitate to say they're also among the most misused tags, because the HTML 5 spec is a little ambiguous.

Web Accessibility and Headings

WCAG 2.0 has 2 main guidelines specific to headings. In a nutshell, your content needs to be logically organized into sections. These sections need to have headings, and the headings need to represent/identify the content they're associated with.

To further understand the spec and how thinking in terms of web accessibility can help, check out HTML 5 Semantics and Accessibility: Heading Structure.

3 comments :

  1. Great post. I suspect I'll forward it to my boss the day I resign.
    It seems to me that there is another huge gap created by this sort of development management.
    Agile say fix the problem in front of you, but most problems are at heart systemic. The number of times I've fixed a bug with what amounts to a hack because fixing the cause is seen as "beyond the scope of the ticket".
    I think some version of agile can be useful during bug-fixing periods, or for maybe 2/3 of a large team during the middle of a big build, but (particularly for completely new projects) you need dedicated framework devs who maintain core consistency, refactor to correct issues, and generally just build all the tools the agile devs will rely on.
    A classic example of this is security. Initially (before release, in the dev environment) security is irrelevant. At some point someone will decide a page needs to be secured, someone will throw together an access security model (totally ignoring data security), and start securing pages.
    That's not how to do security. Security (if it's relevant) should be the first of the foundations an app is built on.
    Yes, it means nothing to show at first, yes it takes one of "those" developers to write it, but with it under everything, it ceases to be an issue. Without it, it will always be incomplete.
    Agile encourages the idea that everything can be broken down into manageable chunks.
    If a manager is a person that thinks 9 women can have a baby in 1 month, then an agile manager is one who thinks they can allocate a different body part to each woman, and expect a fully assembled baby at the end. أحسن موقع عربي للألعاب al3ab66

    ReplyDelete
  2. These provided information was really so nice,thanks for giving that post and the more skills to develop after refer that post. Your articles really impressed for me,because of all information so nice.school promotional video uk

    ReplyDelete
  3. Thanks for the great news! And love hosting! Thanks for sharing this great information!
    wordpress
    blogspot
    youtube
    កីឡាបាល់ទាត់

    ReplyDelete