Web Accessibility is vast and complex. This has become abundantly clear as I endeavour to teach myself the tools necessary to make the Web truly egalitarian, as it was designed to be. As such, this blog is designed to an overview, in an attempt to provide those that are interested in the field a foundation to build upon, as I will continue doing so! It will focus on Semantic HTML and ARIA, two means of providing a web page with the tools necessary to add meaning to its content. Crucially, this is paramount in allowing assistive technology, such as screen readers, to function as intended.


Semantic HTML

Semantics HTML elements are those that _“clearly describes its meaning to both the browser and the developer”¹. _As such, they come with built-in functionality that aids massively in coding for accessibility. Thus, the use of native HTML elements is encouraged, if the website is to be accessible. There are around 100 semantic elements, each with a clear role and meaning. For instance, the

element is semantic as it is clearly intended to be a top level heading on the page. However, a
is not semantic as it has no inherent meaning; we cannot ascertain its contents.

Why use Semantic HTML?

As far as this blog is concerned, the main benefit of semantic HTML is more accessible websites. There are other benefits such as increased Search Engine Optimisation and cleaner code, but that is beyond the scope of this post.

As we touched on before, semantic HTML is code that a screen reader can more readily understand. Using semantic elements such as

,
,

#javascript #accessibility #software-development #wcag #software-engineering

Accessibility Part 3: Semantic HTML and ARIA
1.05 GEEK