Table of Contents for
Responsive Web Design with HTML5 and CSS3 - Second Edition

Version ebook / Retour

Cover image for bash Cookbook, 2nd Edition Responsive Web Design with HTML5 and CSS3 - Second Edition by Ben Frain Published by Packt Publishing, 2015
  1. Cover
  2. Table of Contents
  3. Responsive Web Design with HTML5 and CSS3 Second Edition
  4. Responsive Web Design with HTML5 and CSS3 Second Edition
  5. Credits
  6. About the Author
  7. About the Reviewers
  8. www.PacktPub.com
  9. Preface
  10. What you need for this book
  11. Who this book is for
  12. Conventions
  13. Reader feedback
  14. Customer support
  15. 1. The Essentials of Responsive Web Design
  16. Defining responsive web design
  17. Setting browser support levels
  18. Our first responsive example
  19. The shortcomings of our example
  20. Summary
  21. 2. Media Queries – Supporting Differing Viewports
  22. Media query syntax
  23. Combining media queries
  24. Using media queries to alter a design
  25. Considerations for organizing and authoring media queries
  26. Combine media queries or write them where it suits?
  27. The viewport meta tag
  28. Media Queries Level 4
  29. Summary
  30. 3. Fluid Layouts and Responsive Images
  31. Introducing Flexbox
  32. Getting Flexy
  33. Responsive images
  34. Summary
  35. 4. HTML5 for Responsive Web Designs
  36. Starting an HTML5 page the right way
  37. Easy-going HTML5
  38. New semantic elements in HTML5
  39. HTML5 text-level semantics
  40. Obsolete HTML features
  41. Putting HTML5 elements to use
  42. WCAG and WAI-ARIA for more accessible web applications
  43. Embedding media in HTML5
  44. Responsive HTML5 video and iFrames
  45. A note about 'offline first'
  46. Summary
  47. 5. CSS3 – Selectors, Typography, Color Modes, and New Features
  48. Anatomy of a CSS rule
  49. Quick and useful CSS tricks
  50. Word wrapping
  51. Facilitating feature forks in CSS
  52. New CSS3 selectors and how to use them
  53. CSS3 structural pseudo-classes
  54. CSS custom properties and variables
  55. CSS calc
  56. CSS Level 4 selectors
  57. Web typography
  58. New CSS3 color formats and alpha transparency
  59. Summary
  60. 6. Stunning Aesthetics with CSS3
  61. Box shadows
  62. Background gradients
  63. Repeating gradients
  64. Background gradient patterns
  65. Multiple background images
  66. High-resolution background images
  67. CSS filters
  68. A warning on CSS performance
  69. Summary
  70. 7. Using SVGs for Resolution Independence
  71. The graphic that is a document
  72. Creating SVGs with popular image editing packages and services
  73. Inserting SVGs into your web pages
  74. Inserting an SVG inline
  75. What you can do with each SVG insertion method (inline, object, background-image, and img)
  76. Extra SVG capabilities and oddities
  77. Animating SVG with JavaScript
  78. Optimising SVGs
  79. Using SVGs as filters
  80. A note on media queries inside SVGs
  81. Summary
  82. 8. Transitions, Transformations, and Animations
  83. CSS3 2D transforms
  84. CSS3 3D transformations
  85. Animating with CSS3
  86. Summary
  87. 9. Conquer Forms with HTML5 and CSS3
  88. Understanding the component parts of HTML5 forms
  89. HTML5 input types
  90. How to polyfill non-supporting browsers
  91. Styling HTML5 forms with CSS3
  92. Summary
  93. 10. Approaching a Responsive Web Design
  94. View and use the design on real devices
  95. Embracing progressive enhancement
  96. Defining a browser support matrix
  97. Tiering the user experience
  98. Linking CSS breakpoints to JavaScript
  99. Avoid CSS frameworks in production
  100. Coding pragmatic solutions
  101. Use the simplest code possible
  102. Hiding, showing, and loading content across viewports
  103. Validators and linting tools
  104. Performance
  105. The next big things
  106. Summary
  107. Index

WCAG and WAI-ARIA for more accessible web applications

Even since writing the first edition of this book from 2011 to 2012, the W3C has made strides in making it easier for authors to write more accessible web pages.

WCAG

The WCAG exists to provide:

"a single shared standard for web content accessibility that meets the needs of individuals, organizations, and governments internationally."

When it comes to more pedestrian web pages (as opposed to single page web applications and the like) it makes sense to concentrate on the WCAG guidelines. They offer a number of (mostly common sense) guidelines for how to ensure your web content is accessible. Each recommendation is rated as a conformance level: A, AA, or AAA. For more on these conformance levels look at http://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-levels-head.

You'll probably find that you are already adhering to many of the guidelines, like providing alternative text for images for example. However, you can get a brief run-down of the guidelines at http://www.w3.org/WAI/WCAG20/glance/Overview.html and then build your own custom quick reference list of checks at http://www.w3.org/WAI/WCAG20/quickref/.

I'd encourage everyone to spend an hour or two looking down the list. Many of the guidelines are simple to implement and offer real benefits to users.

WAI-ARIA

The aim of WAI-ARIA is principally to solve the problem of making dynamic content on a web page accessible. It provides a means of describing roles, states, and properties for custom widgets (dynamic sections in web applications) so that they are recognizable and usable by assistive technology users.

For example, if an on-screen widget displays a constantly updating stock price, how would a blind user accessing the page know that? WAI-ARIA attempts to solve these very problems.

Don't use roles for semantic elements

It used to be advisable to add 'landmark' roles to headers and footers like this:

<header role="banner">A header with ARIA landmark banner role</header>

However, this is now considered surplus to requirements. If you look at the specifications for any of the elements listed earlier there is a dedicated Allowed ARIA role attributes section. Here is the relevant explanation from the section element as an example:

"Allowed ARIA role attribute values:

region role (default - do not set), alert, alertdialog, application, contentinfo, dialog, document, log, main, marquee, presentation, search or status."

The key part there being 'role (default - do not set)'. This means that explicitly adding an ARIA role to the element is pointless as it is implied by the element itself. A note in the specification now makes this clear:

"In the majority of cases setting an ARIA role and/or aria-* attribute that matches the default implicit ARIA semantics is unnecessary and not recommended as these properties are already set by the browser."

If you only remember one thing

The easiest thing you can do to aid assistive technologies is to use the correct elements where possible. A header element is going to be far more useful than div class="Header". Similarly, if you have a button on your page, use the <button> element (rather than a span or other element styled to look like a button). I accept that the button element doesn't always allow exact styling (it doesn't like being set to display: table-cell or display: flex for example) and in those instances at least choose the next best thing; usually an <a> tag.

Taking ARIA further

ARIA isn't limited to landmark roles only. To take things further, a full list of the roles and a succinct description of their usage suitability is available at http://www.w3.org/TR/wai-aria/roles.

For a lighter take on the subject, I'd also recommend Heydon Pickering's book, Apps For All: Coding Accessible Web Applications (available at https://shop.smashingmagazine.com/products/apps-for-all-coding-accessible-web-applications).

Tip

Test your designs for free with non-visual desktop access (NVDA)

If you develop on the Windows platform and you'd like to test your ARIA enhanced designs on a screen reader, you can do so for free with NVDA. You can get it at the following URL:

http://www.nvda-project.org/

Google now also ships the free 'Accessibility Developer Tools' for the Chrome browser (available cross-platform); well worth checking out.

There's also a growing number of tools that help quickly test your own designs against things like color blindness. For example, https://michelf.ca/projects/sim-daltonism/ is a Mac app that lets you switch color blindness types and see a preview in a floating palette.

Finally, OS X also includes VoiceOver utility for testing your web pages.

Hopefully, this brief introduction to WAI-ARIA and WCAG has given you enough information to think a little more about how to approach supporting assistive technologies. Perhaps adding assistive technology support to your next HTML5 project will be easier than you think.

As a final resource for all things accessibility, there are handy links and advice galore on the A11Y project home page at http://a11yproject.com/.