Categories
Accessibility Technology Uncategorized

The (not so) Surprising Parallels Between Responsive Design and Accessibility

This is my third session from the first day at the CSUN conference.  This session is hosted by my friend George Zamfir, who I met at this conference last year.  The session guide describes George’s session like so:  “Responsive design has borrowed principles & best practices from accessible design.  Learn about both and how to apply them to your projects.”

Presenter:  George Zamfir (@good_wally)

 

RESOURCES

 

In this post, I’m going to dispense with my normal slide-by-slide narrative structure.  George’s presentation moved way too fast and had lots of builds. 😉

 

George discovered that responsive design was a great way to build accessibility into his projects.  He showed us some of his previous work on the Scotiabank web site.  This ended up being TWO projects:  first for the desktop version of the site, then the mobile responsive version of the site.  He also worked on the mobile version of the bank’s credit card application.

 

What do all assistive technologies have in common?

  • They don’t care much about design, and they care to change it for the user (a lot like RSS readers)
  • Content trumps design, regardless of screen size
  • RWD is not about the design, it’s about updating the design to bring out the content

 

 

Visual, Auditory, Mobility, Cognitive & Speech.  Don’t measure people through the disability lens – which automatically focuses on what people are NOT able to do.  We now measure disability by what people CAN do.

 

Accessibility is contextual, so we should cater to users’ context.  You’re not necessarily engaging with someone working on a desktop computer with a large monitor, keyboard and mouse anymore.  He referred to a study of how people hold their phones and also the W3C’s BAD (Before After Demo) page.

  • One simple tip:  adding padding around text links increases the “hit size”
  • Keyboard accessibility translates well into touch-friendly interfaces.
  • Use native controls wherever possible.  On the bank side, they used <div> instead of <select> control, which was a problem when they went mobile.

 

Design for the edge cases (mobile first design)

If you start with a small screen, prioritization really matters. A variation of this model is designing for edge cases.  If you design for the harshest conditions first, the in-between cases are much easier to work out.  Consider accessibility as one of your edge cases!

 

RWD is a champion for A11Y, we have common goals for our users.

 

Question:  how do you handle navigation in RWD?  I target the simplest possible device and design progressively.

Question:  Do you do anything special about device orientation changes?  Answer:  why would you change the content?  Perhaps you change the layout, but you should not change the content.

Question:  What is your process when you have the luxury of a “clean sheet” design…how do you handle the lowest common denominator?  I like to start with everything besides the content.  We built the framework, and the content just fits into that framework.

Question:  what about hiding content based on context?  How do you handle that? Well, that’s probably not the best way to go…you’re probably doing it wrong if you’re doing it that way.

 

BONUS CONTENT:  CRASH COURSE IN RWD

Foundations of RWD:  fluid foundation, media queries, responsive images.  In short:  Make your layout flexible!

  • Use ratios (ems) and percentages instead of absolute values (px).
  • Adapt to the size of the viewport:  width = device-width, initial-scale=1
  • What apple does is assume that the normal viewport size is 960 pixels, so if you don’t add the viewport declaration, you can get pages with text that’s very small-looking on a small screen.
  • Media Queries in CSS:  start with smallest screen first, and then the larger screens are additive over that definition.
  • Responsive Images:  for simplicity’s sake, start with this: use max-width:100%, height: auto;
Categories
Accessibility Technology Uncategorized

Quirks in Web Standards, Browsers, and Screen Readers

This is my second session of the first day at the CSUN conference, and “takes a look at quirks and bugs in browsers and screen readers, what they mean for users, and how to avoid, fix, or work around them.”  (description is from the conference session guide).  As someone who is actively involved in building consistent web experiences (i.e. browser compatibility), I’m interested in how Ian does this when you add accessible technology into the mix.  Any misinterpretations of Ian’s presentation are entirely my own.  Any errata, please let me know!

Presenter:  Ian Pouncey, Accessibility Specialist, BBC (@IanPouncey)

 

RESOURCES

 

SLIDE ONE

Ian took some time to establish his credibility…

Used to work on the Yahoo! home page, and more recently has been a web developer at the BBC.  Been doing this for about 14 years.  Written a book about CSS from Wrox publishing.

Room was made up of developers, technical folks, screen reader users, and those obliged to come (a little humor).

Ian shared a few slides that were pretty humorous related to “skip to content” links, wherein the humor was related to where you placed the accent on the word content (hopefully he’ll post those slides).

 

SLIDE TWO

Shared a couple pages about skip links from Gez Lemon and Terrilll Thompson, and then demonstrated dynamic skip link code with window.location.hash.

 

SLIDE THREE

Ian showed form error listings and focusing on fields with errors.  Unfortunately, window.location.hash only works reliably in IE!

Ian did a demo of a skip link bug when using off-page content on iOS7.  He prefers using content off-top rather than off-left.  This technique however can result in some interesting behavior, notably showing the skip link after an up-swipe gesture to turn on VoiceOver, and then navigation after that makes the screen go completely blank.

Another option is to use off-screen CSS clipping, which unfortunately results in a lot more code.  This clipping technique is used on about 98% of the BBC web site, so if you want to see it at work, head over there 🙂

 

SLIDE FOUR

Next, Ian shared an ARIA landmark bug in iOS6.  This bug basically announces ALL landmarks in VoiceOver as simply “landmarks,” which is not very helpful.  This bug is resolved by adding a heading to every landmark.

 

SLIDE FIVE

Finally, Ian shared a bug with Live Regions.  You can’t always rely on live regions to provide information to the AT at the appropriate time.

Solution:  JavaScript-added content can be read once it’s been written to the screen.  So, you can build an empty div that quietly waits for content to be written into it.  Be sure to use role status with the assertive attribute.

Categories
Accessibility Technology

Accessibility Features of HTML5

This is my first session of the day Wednesday morning, the first day of the CSUN conference proper.  I’m hoping to get a good overview of HTML5 accessibility features while at the conference this week, so I’m looking forward to this session.  This particular presentation is about the features available in HTML5 that you can use to improve the accessibility of your websites.  Session will include code examples and demonstrations, which I will do my best to capture in this post.

Presenter:

 

RESOURCES

 

 

SLIDE ONE

Introductions, he’s the staff contact for the HTML Accessibility Task Force

HTML5

Open Web Platform

  • Accessibility in the OWP

HTML5 Accessibliity / Demos

  • Improved Semantics
  • ARIA
  • Graphics

 

SLIDE TWO

A description of the HTML Accessibility Task Force.  They have a mandate to develop accessibility solutions, including technical reports, extension specifications, and provide integration paths.  They are about reaching consensus between groups.

 

SLIDE THREE

A very busy graphic describing the “Open Web Platform” which includes virtually any industry or device that needs to connect to the Internet.  Since the web is meant to connect everyone, it needs to be as accessible as possible.

 

SLIDE FOUR

Tim Berners-Lee:  The web is the great equalizer!

 

SLIDE FIVE

  • Added structured access through improved semantics.
  • Ability to bring desktop paradigms into the browser
  • More options for creating text equivalents for graphics
  • Native support for synchronized captions, sign language, internationalization and more.

 

SLIDE SIX

Mark presented a page of code, pretty standard for a blog.  He then ran through the page with VoiceOver.

 

SLIDE SEVEN

HTML5 Has Much Improved Semantics!

It allows you to describe your document structure with sectioning elements, including <section>, <nav>, <article>, <aside>, <header>, <footer>.  You don’t really have to do anything special except use a variety of new sectioning elements.  What makes a useful aside?  A pull quote, comments, etc.

 

SLIDE EIGHT

More information about new semantic elements:  color, date, datetime, email, month, number, range, search, tel, time, url, week

Not all of these will necessarily make it into the HTML5 spec.

 

SLIDE NINE

New attributes for the input element, including autocomplete, autofocus, autosave, list, max/min/step, maxlength, pattern, required, spellcheck.

These will help build forms much easier, particularly the task of form validation.

 

SLIDE TEN

ARIA Landmark roles include:  application, banner, complementary, contentinfo, form, main, navigation, presentation

The ARIA specification was built to provide expose the accessibility API (roles, states, and properties) to accessible technology.  It was designed to allow dynamic web pages to be accessible and provide a more consistent experience for all users.

 

SLIDE ELEVEN

ARIA

  • Accessibility for dynamic content (can be reparative, too)
  • Wired into accessibility APIs (roles, states, and properties)
  • Programmatically link elements with labels and descriptions (aria-label, aria-labelledby, aria-describedby)

 

SLIDE TWELVE

Back to the code sample, only this time Mark replaced most of the <div> elements with a selection of the landmarks noted above.  By marking up the search field, the OS  (Mac in this case) used system styles for the search bar and button.  The demonstration highlighted how VoiceOver announces each section, and using the rotor control, allows the user to directly choose from the various page elements.

One of the things I noticed as Mark was editing his code is that using HTML5 makes hand-coding of web pages and identification of code segments much easier.  If you’ve ever had to deal with multiple nested <divs>, this is definitely something you’ll appreciate.

 

SLIDE THIRTEEN

Much of the benefits come when you view an HTML5-coded page on different platforms.  For example, iOS will bring up a numeric keypad when entering digits telephone number field.  For dates and hours, the OS will present the appropriate pickers, like a calendar or a clock.

 

SLIDE FOURTEEN

Graphics

  • Added <figure> and <figcaption> to allow grouping of images with their description.
  • Provides equivalent interactivity and behavior for dynamic and/or bitmap images <canvas>
  • Provide extended descriptions for complex images <longdesc>
  • Provide detailed guidance to authors  ALT Guidance (4.7.1.1)

 

SLIDE FIFTEEN

  • Canvas allows interaction with pixels on a page, but…they’re just pixels in a box.  Solution:  specify regions
  • How do we define roles/states/properties?  Solution:  map tose regions to Fallback Content.
  • How do we indicate focus?  Solution:  drawFocusIfNeeded()

 

SLIDE SIXTEEN

Mark gave a demonstration of canvas that showed a list of two elements with checkboxes.  What makes this interesting is that those elements were literally just pixels painted onto the screen, but used fallback content.

 

Unfortunately, Mark’s presentation was rather long, and he was unable to complete his presentation and we missed out on seeing his slides on media.

Categories
Accessibility Technology Uncategorized

Implementing ARIA and HTML5 into Modern Web Applications (Part Two)

This is part two of a two-part presentation.  Catch up on part one here:  Introduction to ARIA and HTML5, Part 1

I’m typing this introduction before the presentation begins, and as I understand it, this session will be more technical than the morning session.  I’m not sure how many in-depth code samples will be included (the resources link below hints at what we’ll be talking about), so I’m making an educated guess that I may not be able to capture every nuance.  My apologies in advance if this is the case.

Presenters:

 

RESOURCES

 

EVENT PLUG – TPGBB (The Paciello Group Bug Bash)

  • Wherein you and TPG can ID and squash AT bugs
  • Thursday, March 20, 5:30 – 6:30 PM
  • Suite 3233, Harbor tower, Manchester Grand Hyatt

 

 

STEVE FAULKNER’S SEGMENT

SLIDE ONE

Diving into some HTML5  – an overview of the session

Steve Faulkner talked briefly into his involvement with his having a role in the creation of the HTML specification.  His specific interest is in how APIs speak to AT.

 

SLIDE TWO

Getting Simple

Getting to use native HTML controls makes things simpler for the developers and the AT.

 

SLIDE THREE

HTML5 Demo – details/summary

Here’s an example of the “HTML code triangle” we’re all used to:

<details>

<summary> label </summary>

Some content

</details>

When fully supported, you’ll be able to use native HTML controls without having to use any complicated JavaScript.  In the example above, clicking details would expand and show the contained elements.

Steve then demonstrated in CodePen an example of the code above, and how vastly simplified it is to render these UI elements.  This will make UI/UX designer’s lives much easier.

 

SLIDE FOUR

Chrome, Opera, and Safari have implemented this

Keyboard = 1/2 implemented

 

SLIDE FIVE

Steve then gave a description of how the code above is exposed to the AT APIs (i.e. MSAA).   Put simply, it’s exposed as a <div>, however, it’s not an accurate description of how it’s represented within the DOM.  He then proceeded to show how this looks when viewed through the “Accessibility Viewer” tool.  The aviewer tool is an object inspection tool available from the Paciello Group’s web site at http://www.paciellogroup.com/resources/aviewer.

Not all information is necessarily passed through the API and readable by aviewer.  The hope is that every browser will expose the same API Names, Roles, and States.

 

SLIDE SIX AND SEVEN

What We Want

  • We want to be able to see what’s actually there.
  • We also want to fill the gaps in general support in FF, IE, and webkit browsers

 

SLIDE EIGHT

Steve showed and described the example above, only this time embellished with ARIA code inserted.

 

SLIDE NINE

Showed the details summary here as a working example:  http://www.html5accessibility.com/CSUN14/details.html

The properties of the code on this page are properly exposed by the API, and thus readable as you would expect by aviewer.

 

SLIDE TEN

Dialog

Creating a modal dialog that works with keyboard and prevents users from accessing ‘disable’ content is the holy grail…

Being able to do this within native HTML is something that sure would be awesome.  See next slide…

 

SLIDE ELEVEN

What we get for free:

  • Focus moves to modal dialog when displayed
  • Focus stays until it is dismissed
  • Content not in the modal dialog is really disabled
  • ESC key dismisses it
  • <dialog> = role=dialog

 

SLIDE TWELVE

What we need to add (this only works in Chrome with Canary plug-in at the moment)

  • Accessible name to dialog:  <dialog aria-label=”text”>
  • Currently when the dialog is dismissed, focus moves to <body> when it needs to move to control that triggered dialog display:  can be polyfilled using scripting.

Steve demonstrated accessible modal dialog, once again with CodePen; he was unable to tab “out” of the modal dialog.  It works like a JavaScript alert()

 

SLIDE THIRTEEN

The “good oil” on implementing custom dialogs (I didn’t capture these links, but they’re available in the TPG source slides from the “Resources” link above).

  • Juicy Studio – Custom Built Modal Dialogs
  • The Incredible Accessible Modal Dialog
  • WAI-ARIA design pattern – modal dialog

 

SLIDE FOURTEEN

Input type=number

What we get:

  • Correct role and value information
  • Keyboard operable

Exposed as spin buttons

 

SLIDE FIFTEEN

Input type=range control

Implemented in all browsers.  However, default styling in IE is pretty funky, and they all look different from each other.  Bottom line:  you get everything for free.

 

SLIDE SIXTEEN

There are conformance rules for HTML5, but they can be difficult to decipher.  Steve has a “Using ARIA in HTML” document available for download which can help.

 

SLIDE SEVENTEEN

A large part of what’s been consuming Steve’s life in his role on the HTML5 specification group is figuring out which ARIA Roles, States, and Properties can be used on any HTML element.

 

SLIDE EIGHTEEN

ARIA Validation

  • Use of ARIA in HTML5 is non-conforming and probably always will be.  It doesn’t make any difference, it still works.
  • Easiest method is to use the HTML5 DOCTYPE with ARIA markup and then validate it using the W3C NU markup checker:  http://validator.w3.org/nu/

<!DOCTYPE html>

 

KARL GROVE’S SEGMENT

SLIDE ONE

Live Regions

  • Allows user to be notified of content changes
  • Typically for content that changes automatically
  • Content change may exist separate to what has focus
  • Live Regions facilitate these notifications

ARIA overcomes gaps between what JavaScript has “traditionally” done in web browsers to emulate desktop applications.

 

SLIDE TWO

Karl’s favorite thing to say:  “What is this thing & what does it do?”

  • Chat, error logs, etc. (role=’log’)
  • Status messages (role=’status’)
  • Urgent message requiring immediate notice (role=’alert’)
  • Stock ticker (role=’marquee’)
  • Timer/Clock (role=’timer’)
  • Progress indicator (role=’progressbar’)
  • None of the above (role=’region’)

 

SLIDE THREE

How important is the content?

  • aria-live=’polite’ (waits patiently, default for most roles)
  • aria-live=’assertive’ (interrupts output, default for alert role)

 

SLIDE FOUR

What’s being changed?

  • I’m adding stuff (aria-relevant=’additions’)
  • I’m removing stuff (aria-relevant=’removals’)
  • I’m changing text (aria-relevant=’text’)
  • I’m replacing stuff (aria-relevant=’all’)

Makes relevant changes to the DOM within that live region.  You can change these properties together as needed.

 

SLIDE FIVE

What matters?

  • aria-atomic=’false’ (default behavior, only announces changed node)
  • aria-atomic=’true’ (presents entire contents)

 

SLIDE SIX

What’s my name

A redux of aria labels that was covered in Part One

 

SLIDES SEVEN AND EIGHT

<div role=’alert’ aria-label=”Errors’>

Please correct the following errors:

</div>

Significance of the code above is that it will announce all the mistakes made in a form all at once, which is pretty handy.

 

SLIDE EIGHT

Karl then demonstrated some of the challenges when using live regions with a chat he had set up at:  chat.karlgroves-sandbox.com

He also showed a web-based slideshow called “shower”

Download and play with Karl’s JQuery plug-in at github.com/karlgroves/jquery-live-regions

Short break here…

Karl went about soapboxing:

“ARIA is a LIE and your HTML doesn’t do anything.  They are instead a polite request to the browser about what to do with our code, which is then transformed into a DOM.”

Principle of Least Astonishment:  things should behave consistently

 

HANS’ SEGMENT

SLIDE ONE

  • Keyboard and Focus management
  • Form validation
  • Mode conflicts
  • Solutions, workarounds, and considerations

 

SLIDE TWO

Problem with Custom Controls (not native UI)

Usually created with generic elements like <divs> and <spans>

  • Not keyboard focusable
  • Have a default tab order
  • Behavior unknown

Best solution is to use native controls, or manually define keyboard focus and behavior needs.

 

SLIDE THREE

Keyboard Issues in a Nutshell

  • Reachability:  via tab order, globally defined shortcut, activating another widget
  • Operability:  all functionality should be doable via keyboard and mouse input.

 

SLIDE FOUR

To be accessible, ARIA input widgets need focus.

  • Tabindex=”0″ element becomes a part of the tab order
  • Tabindex=”-1″ element is not in tab order, but focusable

Each widget should have only one stop in the tab order.  All of your widgets should be reachable via keyboard.  Hans then gave a demonstration of a tree widget, tabbing both into and out of it using JAWS.  This demonstration also pointed out the danger of wrapping a page with a role of application.

An alternative for a roving tabindex is the aria-activedescendant=”<idref>”

 

SLIDE FIVE

Every widget needs to be operable by keyboard.  Common keystrokes are:

  • Arrow keys, home, end, page up, page down, enter, space, esc
  • Mimic navigation in the desktop environment when possible:  www.w3.org/WAI/PF/aria-practices
  • Always manage and keep track of your focus.  Never let it get lost.

To demonstrate focus, Hans showed a table that allowed deletion of columns of data.  After deleting a column, the previous column received focus.

 

SLIDE SIX

Skipping Mechanisms

  • Ability to skip content is crucial for screen reader and keyboard users
  • Skip links may be out of fashion and often misused, but users still need to be able to skip.
  • Alternatives:  collapsible sections, consistent shortcuts, custom focus manager

 

SLIDE SEVEN

Form validation

  • ARIA makes form validation easier to manage:  aria-required & aria-invalid states, role=”alert” flags validation errors immediately.  Inline and error summary used together are most effective.
  • Validation summaries make invalid entries easier to find

Create a programmatic connection between validation messages and their associated fields.  Maybe there needs to be a W3C specification about how AT is supposed to behave (there’s one for UA).  Hans provided a demonstration of a sample form with required fields.  Tabbing away from a required field activated the “required” error when tabbing into the following field.  He attempted to mark up the fields as live regions, but it didn’t work very well.

 

SLIDE EIGHT

Fallback solutions for link buttons

There’s no real consensus on links versus buttons.  Set role=”button” to make links look like buttons for screen readers

 

SLIDE NINE

Mode conflicts, i.e. Role=Application

  • Screen readers normally browse in ‘virtual mode.’  This means it navigates a virtual copy of the web page.  It intercepts all keystrokes for its own navigation (i.e. “H” for heading navigation.
  • For dynamic web apps, virtual mode may need to be turned off.  Interactive widgets need to define the keystrokes themselves; content needs to be live, not a virtual copy; automatically switches between virtual and non-virtual mode.
  • role=”application”:  screen reader switches to non-virtual for these elements; must provide all keyboard navigation when in role=”application” mode; screen readers don’t intercept keystrokes then, so typical functions will not work.

 

SLIDE TEN

Role=Document

  • For apps with reading or editing sections (e-mail client)
  • When applied to a container inside an application role, the screen reader switches to virtual mode.

Only use application role when your application actually IS a web application.

 

SLIDE ELEVEN

Explain to users how Rich Internet Applications work

Put some hidden text at the beginning of the page to explain.

 

SLIDE TWELVE

The perfect dialog, in theory

  • Use role=”dialog” combined with aria-labelledby (for dialog title), aria-describedby (for dialog message text)
  • Focus management
  • For modal dialogs:  prevent virtual navigation to background using aria-hidden=”true”

 

Categories
Accessibility Technology

Introduction to ARIA and HTML5 – Part 1

This presentation is a two-parter, this is part one.  If you want to skip ahead to part two, this is the link you’re looking for:  Implementing ARIA and HTML5 into Modern Web Applications (Part Two)

Presenters:

  • Jared Smith from WebAIM (@jared_w_smith)
  • Jonathan Whiting from WebAIM

For those who don’t know, WebAIM is from Utah State University.  Here are some resources that were cited during the presentation:

 

SLIDE ONE

Requiring JavaScript is not an accessibility question…it’s a general usability question.

 

SLIDE TWO

WebAIM Surveys of Users with Disabilities >98% of respondents have JavaScript enabled.  Upshot:  if you’re going to do scripting, you have to do it accessibly.

  • You’re probably better off to have your scripts fail entirely rather just partially.
  • Progressive enhancement allows you to retain functionality regardless of browser capabilities.

 

SLIDE THREE

“Freak out mode”  occurs with screen readers when the currently focused page element disappears or is significantly modified via DOM manipulation, refreshes or other control changes.  Avoid it or address it by setting focus();

  • Mentioned the common use of carousels and other frequently refreshing content

 

SLIDE FOUR

JavaScript prompt, alerts, and confirmations are screen reader accessible!

 

SLIDE FIVE

Ensure Device Independence.  Functionality available to mouse users must be available to keyboard users

 

SLIDE SIX

CAPTCHA – Completely Automated Patience Test to Confuse the Hell out of your Audience (humor with some scattered chuckles and guffaws).  There are ways to accomplish the goals of CAPTCHA – that is, proving you’re a human – while avoiding its use.

 

SLIDE SEVEN

ARIA

  • Accessible Rich Internet Applications
  • Specification developed by the PFWG of the W3C’s WAI (Protocols and Formats Working Group of the World Wide Web Consortium’s Web Accessibility Initiative)
  • W3C Proposed Recommendation (final step before formal recommendation)

Implementation by browser vendors has actually been quickly adopted by comparison with other web technologies like CSS.

 

SLIDE EIGHT

ARIA Enhances accessibility of…

  • …dynamic content and AJAX
  • …scripted widgets and interactive controls
  • …keyboard interactions within a web page

ARIA bridges the gap to future versions of HTML

An example of a widget that is not available natively in HTML is the slider.  Screen readers know what a slider is, and they are able to read ARIA code and interpret it.

 

SLIDE NINE

Screen readers understand a fairly broad vocabulary, but HTML’s dictionary is very limited.  ARIA expands HTML’s semantic vocabulary.  ARIA fills in the vocabulary needed to express functions needed.  It “paves the cow paths.”  In a sense, ARIA “paves the cow paths.”  They showed a series of photos of “cow paths” at Utah State University.

 

SLIDE TEN

You can only make things more accessible by implementing ARIA now…if you do it correctly.  Some older versions of browsers and screen readers won’t read some features properly.  In that case, ARIA won’t break the page, the technology just won’t see it.  A common interaction now are light boxes that will close when pressing the escape key.

 

SLIDE ELEVEN

ARIA Core Components

  • Roles:  this is what this thing is <form role=”search”>
  • States: this is the condition of this thing <input aria-disabled=”true”>
  • Properties: this is a property of this thing <input aria-required=”true”>

HTML has default states and properties.  In ARIA, there is no limit to the number of states and properties a core component can have.  While you can include lots of states and properties to your components, you need to be cautious about overloading your users with too much information.  There is a sweet spot, though.  More info in a post here:  http://webaim.org/blog/loss-aversion-and-web-accessibility/

 

SLIDE TWELVE

ARIA and Code Validation

  • If your (X)HTML is valid and your ARIA is valid…
  • valid+valid=??

Your ARIA markup may be completely valid, but many validators will show that your ARIA code is invalid.  ARIA is a part of HTML5 spec, so if you code is marked up as HTML5, you’re less likely to get validation errors.

 

SLIDE THIRTEEN

ARIA Landmark Roles

  • Banner:  complementary, contentinfo, main, navigation and search
  • Allows easy access to major page components
  • The end of the “skip” link?  No, browser keyboard accessibility still sucks so you should keep using it.

If browsers would implement navigation via headings and landmarks, the skip link could go away.  Consumers should bug the browser vendors if they want better accessibility in their tools.

Question from the audience:  are there SEO benefits for implementing ARIA?  I don’t know, but in the future there may be benefits for content landmarks like “main”

 

SLIDE FOURTEEN

Landmark Roles – some examples

  • <div role=”main”>
  • <form role=”search”>
  • <div role=”navigation” aria-label=”Main navigation”>

You can add aria-label to differentiate multiple landmarks of the same type

 

SLIDE FIFTEEN

Landmark Roles

  • Don’t overdo it!
  • Not all lnks are navigation
  • It is assumed that the footer will contain some links.  It todoesn’t need navigation also

 

SLIDE SIXTEEN

HTML5 and Landmark Roles Mapping

  • <main> – role=”main”
  • <article – role=”article”
  • <footer> – role=”contentinfo”
  • <header> – role=”banner”
  • <nav> – role=”navigation”
  • <aside> – role=”complementary”

ARIA support is better than HTML5 support, so use both…for now

 

SLIDE SEVENTEEN

Modifying and Enhancing Roles

  • Bad:  <img src=”submit.jpg” onclick=…>
  • OK:  <a onclick=”…”><img src=”submit.jpg”…
  • Better: <a role=”button” onclick=”…”><img src=”submit.jpg”…
  • Best:  <button onclick=”…”>

Always start with native HTML

 

SLIDE EIGHTEEN

Always use native, accessible HTML first, then use ARIA to enhance or fill in gaps.  Use controls that convey the correct semantic meaning wherever possible.  Above all, be consistent!

 

SLIDE NINETEEN

ARIA does not change functionality, it only changes the presented roles/properties to screen reader users.  WebAIM’s WAVE toolbar identifies ARIA roles on the page.

 

SLIDE TWENTY

If there’s a conflict between native HTML roles/attribute and ARIA roles/attributes…ARIA wins!

Example:  <input type=”radio” role=”checkbox”>

How is the above code presented to the user?  As a checkbox.

 

SLIDE TWENTY ONE

role=”application”

….routes key commands to the browser to allow it to function like a desktop application

Be very careful with <body role=”application”>

Some ARIA elements (tree view, slider, table, tabs, dialog, toolbar, menus, etc.) have an assumed application role

role=”document” should enable reading mode

An example of confusing behavior could be pressing the “h” key opening a help dialog instead of the default jump to next heading.

Paul Schantz comment:  It seems like by invoking application mode, the developer is making two big assumptions:  1) the screen reader user is advanced, and 2) the user is going to use your application an awful lot.

Hans Hillen comment:  use application role when 1) you can guarantee that your app will actually behave like an app, or 2) that this is a highly controlled intranet-style application

 

SLIDE TWENTY TWO

role=”presentation”

<ul role=”presentation”>

<li>menu item</li>…

Hides native roles of elements and all required owned child elements from assistive technology.  Useful on layout tables, lists, etc.

Is ignored if the element is navigable (e.g., links and controls).

 

SLIDE TWENTY THREE

Alert Role

  • <div role=”alert”>Read me right now</div>
  • Also role=”alertdialog”

Use this role only for really important alerts!  An alert is a special type of live region

 

SLIDE TWENTY FOUR

Form field example with a “First Name” field

<label for=”name”>First Name</label>:

<input name=”name” id=”name”><em>(required)</em>

The information about the element being required is outside the form element and its label, so it’s ignored by a screen reader

 

SLIDE TWENTY FIVE

<label for=”name”>First Name</label>:

<input name=”name” id=”name” aria=required=”true”><em>(required)</em>

A screen reader now indicates the required status of the form element (and that’s all).

 

SLIDE TWENTY SIX

Form field example using a Password field

<label for=”password”>Password</label>;

<input name=”password” id=”password” aria-invalid=”true”>

A screen reader no indicates that the field is invalid or broken (and that’s all).

Use ARIA attributes to control styling:

(aria-invalid=true) (border : 2px solid red;)

 

SLIDE TWENTY SEVEN

<input type=”submit” disabled=”disabled”>

…versus…

<input type=”submit” aria-disabled=”true”>

Disabled HTML buttons are not keyboard focusable and have very poor contrast.

 

SLIDE TWENTY EIGHT

Use scripting to change aria-disabled value, then use CSS to control the visual presentation:

[aria-disabled=true] (color : #999;)

aria-disabled does not disable the button, it simply presents it as disabled to screen reader users.

 

SLIDE TWENTY NINE

aria-hidden=”true”

Indicates element (and all descendants) are hidden from all (???) users.

You can’t unhide a child element.

Use ARIA attributes to control visual appearance:

[aria-hidden=true] (display:none;}

 

SLIDE THIRTY

First Name form field example

<label for=”name” id=”fnamelabel”>First name</label>:

<input type=”text” id=”fname” aria-labelledby=”fnamelabel”>

Redundant, but doesn’t cause any problems.  Remember, ARIA always overrides native semantics.  Use aria-labelled by when you already have a textual description on the page.

There were then a few example slides that showed labeling examples with forms, multiple fields in a grid, and so on.

 

SLIDE THIRTY ONE

ARIA Live Regions

aria-live=”off | polite | assertive”

  • aria-busy
  • aria-atomic – read the entire region or only what has changed
  • aria-relevant – additions, removals, text, or all
  • aria-controls
  • Special live regions:  alert(important), status (not important), timer(always changing), marquee(same as aria-live=”polite”), and log(updates added to the bottom)

 

SLIDE THIRTY TWO

ARIA Live Regions

Some highly dynamic content updates simply cannot be made accessible using ARIA.  Be sure to give users control over content updates

 

SLIDE THIRTY THREE

ARIA Lists

A code example was here with <divs> and lists

Could use aria-checked=true|false|mixed to make it interactive

 

SLIDE THIRTY FOUR

ARIA ‘fieldset/legend’

A code example was here with <divs> and radio buttons

Radiogroup is not reserved only for radio buttons

 

SLIDE THIRTY FIVE

ARIA Table Caption

<h2 id=”salescaption”>2013 Sales Data</h2>

<p>Sales increased by…</p>

<table aria-describedby=”salescaption”>

 

SLIDE THIRTY SIX

ARIA Pop-ups/Dialogs and ARIA Expanded

<a aria-haspopup=”true”>Option dialog</a>

<a aria-expanded=”false”>Expand details</a>

 

SLIDE THIRTY SEVEN

Odds & Ends:  menus, tablists, grids

 

SLIDE THIRTY EIGHT

ARIA Design Patterns for Widget Interaction

 

 

SLIDE THIRTY NINE

HTML5

  • Adds new features- primarily for application development and enhanced semantics
  • Maintains backward compatibility (mostly)
  • Defines error handling for browsers
  • Drops all (actually most) presentational markup

 

SLIDE FORTY

HTML5 History

A slide with a timeline that contained lots of dates that showed the history (too many bullets to capture…sorry!)

 

SLIDE FORTY ONE

HTML5 Philosophy

  1. Why make authors do something that the browser can do for them?
  2. Things that actually work matter most.

 

SLIDE FORTY TWO

HTML5 Doctype

<!DOCTYPE html>

  • The last DOCTYPE you’ll ever use?
  • HTML versions vs. HTML the “living standard”
  • HTML is very much a work in progress

If you write it and the browser supports it, then you’re good!

 

SLIDE FORTY THREE

HTML5 Simplifications

  • HTML5 is case insensitive
  • Quoted single-word attribute values are not required.  Example <label for=fname> is acceptable
  • Don’t have to self close elements

There were then a series of slides that demonstrated a series of code simplifications, including language, charset, CSS type, script, style type.

 

SLIDE FORTY FOUR

The smallest valid accessible HTML5 Document:

<!doctype html>

<html lang=en>

<meta charset=utf-8>

<title>blah</title>

<p>I’m the content</p>

HTML5 allows browsers to do much of the work.  Just because you can, doesn’t mean that you should.

 

SLIDE FORTY FIVE

HTML5 Changes

Dropped:  <acronym>, <applet>, <frameset>, <font>, <s> (strike), <big>, <center>

Maintained:  <b>, <em>, <i>, <strong>, <small>, (side comments), <u>, and <cite>

 

SLIDE FORTY SIX

New HTML5 Elements

  • nav
  • header
  • main
  • footer
  • article
  • section
  • aside
  • …and more

 

SLIDE FORTY SEVEN

HTML5 Sectioning Elements

  • <section>, <article>, <aside> and <nav>
  • Each should generally begin with a heading that describes that section
  • <article> is self-contained, syndicatable
  • The outline presented to the user may be different than the heading structure defined

A blog was given as an example of how the outline presentation might work.  Each blog post title will logically have an <h1> within the page of the post itself, while in a table of contents on the site home page, those <h1> might be shifted to <h2>

If you’re going to use these items, just use proper headings!

 

SLIDE FORTY EIGHT

HTML5 Accessibility Changes

  • Alt attribute is optional when <figcaption> presents an equivalent alternative for an image within a <figure>
  • Dropped longdesc (subject to change)
  • Dropped table summary
  • ARIA markup is valid
  • <video> and <audio> natively support captioning

More details here on browser support:  http://www.html5accessibility.com/

 

SLIDE FORTY NINE

New HTML5 Input Types

  • search, number, range, color, url, email, tel, date, month, week, time, datetime, datetime-local
  • New form attributes: – required, pattern, autocomplete, placeholder, autofocus, etc.
  • The browser can (or, more accurately, hopefully will) provide a natively accessible control/interface

 

SLIDE FIFTY