UX Engineering in Public
My previous knowledge has always been to override browser default and provide custom styles and behavior for elements.
I’ve recently learnt that we don’t need to do that. There’re a lot of experienced people who ensure that things work on the web.
Making Custom Things
If we want to make a custom element, we would write the HTML, event handlers, and imitate consistent behaviors on Web (Different browsers), Android, iOS, Mac, Windows etc.
How would screen readers announce it? How would browsers describe it? How would search engines differentiate it from other elements on the page? How would RSS readers correctly present the content?
But when we use a standard element like a button, we get all that for free.
Semantic HTML is leveraging the hard work of awesome people who’s job is to make the web accessible to anyone, anywhere. If you’re concerned about accessibility, you should begin from markup. Markup is the basis of accessibility.
On the other hand, we could make use of ARIA (Accessible Rich Internet Applications) APIs to enhance the experience for screen readers and assistive technology. For instance, if a button toggles a menu, we could communicate the state of the menu to the reader. Here’s how we would achieve this
<button aria-expanded="false"></button> <div hidden>Some Menu Content</div>
aria-expanded attribute to
true when the menu shows. This will communicate useful information to the browser and screen readers like what is on screen and what isn’t.
Choosing elements based on Meaning
Every HTML element is specifically useful in describing the contents of the page. A page with lots of
spans and less semantic elements is on the far meaningless spectrum while one with less
divs and more HTML5 elements is more meaningful.
Semantic HTML elements are chosen based on their meaning and not their styling. Styling can be fixed with CSS. HTML is concerned with structure and meaning alone. We can go a long way by
- Using one H1 per page and ensuring other headings are used with appropriate hierarchy. E.g, use a H2 first before a H3, rather than manipulate the
font-sizeattribute with CSS to achieve hierarchy.
- Using the most appropriate HTML element for the content.
ARIA (Assistive Rich Internet Applications), is a spec from the World Wide Web Consortium (W3C) that was created to improve accessibility of web pages and applications by providing extra information to screen readers via HTML attributes.
ARIA attributes are divided into two categories: roles, and states & properties.
ARIA roles are used to communicate the role of an element on the page. There’s four categories of ARIA-roles
Landmarks ARIA Roles:
Screen readers for blind and visually impaired users use these ARIA attributes to get a broader view of the web page and easily jump to different sections. Think of a user who wants to jump straight to the main content.
While there’s a
main tag, setting the
role attribute to
main on the
main element will make it easier to navigate to the main content. The same also applies for
nav elements too. Here’s the different values of the
- banner: element containing the main title of the page.
- complementary: Content aside from the main content, but is meaningful on it’s own. e.g
- contentinfo: A section providing more information about the parent document. Think copyright info, general links, references etc.
- form: Block of content for entering information
- main: Main section of a page
- navigation: Any section containing important links for primary navigation.
- search: The search component of a page.
- application: Used to describe a part of the site that is more interactive than normal document centered pages.
Checkout Using ARIA landmarks to identify regions of a page for more info.
Document ARIA Roles
While Landmark roles describe sections of a webpage, document roles describe the structure of content on the page. Examples of common ones are
Widget ARIA Roles
- alert: Elements with important, time-sensitive content
- alertdialog: A dialog showing an important message and takes initial focus.
- button: No brainer
- dialog: Interrupts the use to collect information from the user
- radio: Describes a radio button
- tab: Navigation for iterating tab content
- tabpanel: A container for content controlled by a tab navigation
- textbox: form element for free text entry
ARIA States & Properties
ARIA states and properties are used to support ARIA roles on a page. Think of them as describing the relationship between 2 or more elements on a page.
There’s a comprehensive list of all ARIA states & Properties on ARIA Roles, States & Properties