- Text is readable by people with low vision.
- Luminosity difference aids color blindness.
- 4.5:1 for small text
- 3.0:1 for large text (18pt/14pt Bold) (24px/19px Bold)
- 2.5:1 for links
Short answer: Don't use them, except in special circumstances.
HTML title
attributes are often perceived as an accessibility (and SEO) bonus, but the opposite is true. For screen reader users the content included inside of the title
attribute is typically unncessary, redundant, and possibly not even used. Conversely, content being put in the title
attribute is being hidden from the (probable) majority of your users. If information is being hidden from the majority of your users, then it's probably not necessary.
There are a few times when using a title
attribute is appropriate:
<frame>
and <iframe>
elementsA common misconception among web developers is that screen readers only read the non-JavaScript page. Due to this misconception, we sometimes assume it's unnecessary to make JavaScript apps and other functionality accessible. This is categorically false.
According to a May 2012 survey conducted by WebAIM, 98.6% of screen reader users have JavaScript enabled.
Be sure to make efforts to ensure that the JavaScript functionality (apps, custom UI controls, forms, etc) within your site is accessible. It could be as simple as opting for native links and form inputs instead of custom scripted form elements.
Summary: Use role="application"
very sparingly, if at all.
NEVER use role="application"
on a widely containing element such as <body>
if your page consists mostly of traditional widgets or page elements such as links that the user does not have to interact with in focus mode. Using role="application"
unnecessarily can cause huge headaches for any assistive technology user trying to use your site/application. Only put it on the <body>
element if your page consists solely of a widget or set of widgets that all need the focus mode[^focusmode] to be turned on.
Do Use
layout | title | description | categories | |
---|---|---|---|---|
post |
How-to: Future proof your accessibility efforts.
|
Ways to make your accessibility effort as future proof as possible. |
|
layout | title | description | categories | |
---|---|---|---|---|
post |
How-to: Future proof your accessibility efforts.
|
Ways to make your accessibility effort as future proof as possible. |
|
Backstory: I decided to crowdsource static site generator recommendations, so the following are actual real world suggested-to-me results. I then took those and sorted them by language/server and, just for a decent relative metric, their Github Watcher count. If you want a heap of other projects (including other languages like Haskell and Python) Nanoc has the mother of all site generator lists. If you recommend another one, by all means add a comment.
<h1>Contact</h1> | |
<form action="#" method="post"> | |
<div> | |
<label for="name">Text Input:</label> | |
<input type="text" name="name" id="name" value="" tabindex="1" /> | |
</div> | |
<div> | |
<h4>Radio Button Choice</h4> | |
<?php | |
// Register widgetized sidebar. | |
register_sidebar(array( | |
// See: http://codex.wordpress.org/Function_Reference/register_sidebar | |
'before_title' => '', | |
'after_title' => '' | |
)); | |
add_filter( 'widget_title', 'remove_widget_titles'); | |
function remove_widget_titles( $widget_title ) { |