# Standards and Accessibility

Published:

This lesson covers Standards and Accessibility

# Standards and Accessibility

• ensure that web pages and applications can be used by everyone, regardless of their choice of web browser or their own physical abilities.

• Using semantically meaningful HTML tags
• Providing alternate text for visual features (i.e., images)
• Describing the role of elements on your page
• Hiding unnecessary content from screen readers
• Web Standards

• agreed-upon specifications for how web page source code should be rendered by the browser.
• detail both the language syntax (e.g., how to write HTML tags) and the language semantics (e.g., which HTML tags to use), so that it can be understood by any browser that follows (agrees to) that standard.
• World Wide Web Consortium (W3C)

• includes major browser developers such as Google and Mozilla.
• no enforcement powers: and so browsers often deviate from the published standards!
• If a webpage conforms to web standards, then it will work on all “modern browsers”—though there may still be a few cross-browser compatibility concerns to notice.
• Test and validate your code against the standards

• W3C Developer Tools for a complete list of validators, http://w3c.github.io/developers/tools/
• W3C HTML Validation Service, https://validator.w3.org/nu/
• W3C CSS Validation Service, http://jigsaw.w3.org/css-validator/
• Why Accessibility

• JAWS, Job Access With Speech
• https://www.freedomscientific.com/Products/software/JAWS/
• is the world’s most popular screen reader, developed for computer users whose vision loss prevents them from seeing screen content or navigating with a mouse.
• JAWS provides speech and Braille output for the most popular computer applications on your PC. You will be able to navigate the Internet, write a document, read an email and create presentations from your office, remote desktop, or from home.
• Vision Impairments
• People who cannot see use alternate mediums for reading web pages.
• Farsightedness and other vision problems are also very common (particularly among older adults), requiring larger and clearer text.
• Many people are color-blind.
• Motor Impairments
• Arthritis can restrict people’s ease at using a mouse, keyboard or touch screen.
• Other impairments such as tremors, motor-neuron conditions, and paralysis may further impact people’s access.
• Cognitive Impairments
• Autism, dyslexia, and language barriers may cause people to be excluded from utilizing your website.
• Facebook has an entire team devoted to accessibility and supporting users with disabilities. “Accessibility Engineers” have good job prospects.
• Supporting users with disabilities is not just the morally correct thing to do, it’s also the law.
• Universal Design (a.k.a. universal usability)
• designing for accessibility—being usable by all people no matter their ability (physical or otherwise)
• benefits not just those with some form of limitation or disability, but everyone
• If you support people who can’t see, then you may also support people who can’t see right now (e.g., because of a bad glare on their screen).
• If you support people with motor impairments, then you may also support people trying to use your website without a mouse (e.g., from a laptop while on a bumpy bus).
• If you support people with cognitive impairments, then you may also support people who are temporarily impaired (e.g., inebriated or lacking sleep).
• a web page that is well-structured and navigable by screen readers
• will be navigable by other machines, such as search engine indexers.
• Or for unusual or future browsers (a virtual reality browser perhaps)
• Thus supporting accessibility in client-side web development is important both for helping a population that is often overlooked (a form of social justice), as well as for supporting new technologies and systems.
• Supporting Accessibility

• is a piece of software that is able to synthesize and “read” content on a computer’s screen out loud through the speakers, so that users are able to navigate and control the computer without needing to see the screen.
• Screen readers are often combined with keyboard controls, so that users use just the keyboard to control the computer and not the mouse (almost like a command line interface!).
• interpret the HTML of a website in order to allow the user to hear and navigate the content—they are basically non-visual web browsers. As such, supporting screen readers just means implementing your web site so it works with this browser.
• Different screen reader software packages:
• Mac - VoiceOver
• Windows - Microsoft Narrator
• JAWS and NDVA
• Web Accessibility Content Guidelines (WCAG)
• Principles and techniques to utilize when authoring HTML documents in order to make sure that they are accessible. The guidelines are driven by 4 main principles:
• Perceivable:
• Information and user interface components must be presentable to users in ways they can perceive.
• Operable
• User interface components and navigation must be operable.
• Understandable
• Information and the operation of user interfaces must be understandable.
• Robust
• Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.
• Semantic HTML

• HTML is just for semantics. CSS is for appearance.

• HTML elements should be used to describe the meaning or form of their content, not to give that content a visual appearance!

• php+HTML <!DOCTYPE html>

# This is a real heading!

This just LOOKS like a heading.

</html> 

• A screen reader will (mostly) ignore the CSS

• Only use elements when they are semantically appropriate—don’t use an <h3>element just because you want text to look bigger if it isn’t actually a third-level heading (use CSS to do the styling instead).

• HTML 5 includes a large number of semantic elements that can be used to indicate “formatted” text that has a particular meaning

• <abbr>, <address>, <cite>, <del>, <dfn>, <mark>, and <time>

• Accessible Rich Internet Applications Suite (ARIA)

• ARIA specifies an extension to HTML, defining additional HTML attributes that can be included in elements in order to provide additional support for screen readers.

• For example, ARIA provides additional support to help screen readers navigate through a page (for people who can’t just visually scroll), as well as providing a mechanism by which “rich” interactive web apps can communicate their behavior to screen readers.

• Roles for interactive widgets

• For example, the ARIA specification defines a role attribute that allows non-semantic elements (such as <div> elements) to specify their semantic purpose e.g. button, popup dialog, progressbar, or menu

• <div class="btn" role="button">Submit</div>

• Unsemantic div element is styled (via css) to look like a button and given role as button
• Landmark roles

• indicate specific locations in the document, to allow the screen reader to easily “jump” to different sections of the content (thus making the page navigable).
• banner
• at the top of the page, content related to the website rather than to the specific page itself
• Alternatively, use the <header> element (role=banner attribute is implied)
• a section of links for moving around the page, such as a navigation bar.
• Alternatively, use the <nav>
• main
• This is useful for allowing the screen reader to jump to the meat of the page, past the banner and navigation sections. Alternatively, use the <main> element
• contentinfo
• a section that contains information about the webpage, such as author contact info and copyright information.
• This is usually found at the bottom of the page.
• Alternatively, use the <footer>
• Page Structure (Navigable)

• Heading elements (<h1>, <h2>, etc).

• Headings are useful when they are meaningful

• represents header or introduction part of the page, such as the title or banner image.
• may also include common page elements such as navigation or search bars.
• This corresponds to the role="banner" landmark role; you do not need to include that role if you use this element.
• <header>, heading (<h1>), <head> are all different
• nav, <nav>

• Not all links need to be in a <nav>; this is for “sections” of the webpage that are purely navigational. This element corresponds to the role=”navigation” landmark role.
• main, <main>

• usually comes after the <header> (but not inside—in fact, <main> cannot be a descendant of <header>).
• Note that a web page can only have a single <main> element. This element corresponds to the role=”main” landmark role.
• footer, <footer>

• represents the footer of the page, usually containing information about the page.
• This element corresponds to the role=”contentinfo” landmark role
• section, <section>

• represents a standalone section of content (e.g., that might have a subheading such as <h3>).
• A <section> can also contain its own <header>, <footer>, and <nav> elements relevant to that section.
• article, <article>

• element also represents standalone content, but content that might be published independently (such as a news article or a blog post).
• Note that a <section> may group together multiple <article> elements (such as a blog roll), and an <article> might potentially contain more than one <section>.
• Think about how a newspaper is structured (with a “Sports Section” that contains articles, which may themselves have different sections).
• !-- Starting from the body tag -->
<body>
<nav>
</nav>

<!-- Main page content -->
<main>
<section>
content...
</section>
<section>
content...
</section>
</main>

<!-- Page footer -->
<footer>
</footer>
</body>

• Visual Information (Perceivable)

• interactive elements may be labeled visually (e.g., a search button that with a magnifying glass icon).

• img,

• should always include an alt attribute that gives alternate text for when the images cannot be displayed (e.g., on screen readers, but also if the image fails to load)

• <img src="baby_picture.jpg" alt="a cute baby">

• This will be read by screen readers as “a cute baby, image”. Note that the “alt-text” should not include introductory text such as “a picture of”, as screen readers will already report that something is an image
• longdesc

• for more complex images (such as charts or infographics), we can instead provide a link to a longer description by using the longdesc attribute.

• <img src="accessibility_infographic.png"
alt="an infographic showing how to make web pages accessible"
longdesc="infographic_text.html"> <!-- link to other page with text description -->

• figcaption, <figcaption>

• <figure>
<img src="chart.png" alt="a chart showing some information">
<figcaption>
A caption for the above figure. It provides the same information,
but in a text format.
</figcaption>
</figure>

• aria-hidden

• can cause a screen reader to “skip” the elements that are purely decorative: company logos, icons that accompany text descriptions on buttons

• <!-- a search button with an icon -->
<!-- the icon img will not be read, but the button text will be -->
<button><img src="search_icon.png" aria-hidden="true">Search</button>

• aria-labels

• acts like the alt attribute for any element, specifying what text should be read in place of the normal content

• <div class="green-rect" aria-label="a giant green rectangle"></div>

• aria-describedby

• For longer descriptions, use the aria-describedby attribute to include a reference to the id of a different element on the same page that contains the textual description.

• aria-describedby takes as a value a fragment reference (similar to a bookmark hyperlink) to the element containing the description.

• <div class="green-rect" aria-describedby="#rectDetail"></div>

<p id="rectDetail">The above rectangle is giant and green.</p>