Author: Dennis

Categories
application gaad image twitter

Easy Chirp now provides accessible images for your Tweets

Although improving, accessibility of Twitter and third-party applications has been an issue over the years, and even more so, the images within tweets.

You can now provide accessible images for your Tweets using the web-accessible Twitter client Easy Chirp (@EasyChirp) which allows a title (a short description) and a long description to be entered along with the image. The title is required.

EasyChirp2 logo beta

This announcement comes on May 15 in recognition of Global Accessibility Awareness Day (#GAAD).

Web Axe author Dennis Lembree is also the founder of Easy Chirp. Last month, Mark Sadecki of the W3C (@cptvitamin) approached Dennis with an idea for authoring/posting accessible images on twitter. Together they brainstormed a plan.

Dennis implemented the plan within a couple weeks but ran into issues during testing. Proper support for the longdesc attribute is still behind in some browsers and assistive technologies. To ensure that everyone has access to the long description, it will also appear directly in the content of the page. Addendum: Here’s an example of the final image page.

Easy Chirp also provides a help page which explains the difference between a short and long description and provides information on a couple limitations of the feature.

To create a tweet with an accessible image:

  1. Log in to Easy Chirp with your Twitter account.
  2. Select Write Tweet.
  3. Select Add Image.
  4. Select an image from your device.
  5. Enter a title of the image (short description).
  6. If necessary, enter a long description of the image.
  7. Click the Upload Image button. A URL will be inserted in the tweet input (textarea).
  8. Finish writing the tweet and click the Post button.
  9. Happiness!

Please help the accessibility of the Twittersphere and write a long description or two. Need some ideas? Here are some tweets with interesting images that you can re-post. But be sure to credit the original author!

The image hosting service itself is provided via the Imgur API. Easy Chirp also provides some help and tips on its alt text feature.

Categories
color gaad roundup wordpress

Round Up: SVG, ARIA, GAAD, WP, Ai Squared

Some great links of late:

Categories
html5 table

Clearing Up Summary

The summary attribute is a “classic” method to describe data tables to screen readers users. It’s mentioned in Section 508 and even in WCAG 2.0 technique H73. But this technique is outdated and I haven’t recommended its use for a while now.

Reasons not to use the summary attribute

Why don’t I recommended its use? Here are some reasons:

  • Many web editors don’t support it.
  • Because it’s not visual, the content can be easily be forgotten and therefore outdated/irrelevant.
  • Screen readers can automatically tell the user how many rows and columns a data table has so summary isn’t needed for this.
  • It’s deprecated in HTML5.
  • There is an ARIA alternative.

Misinformation

In the past, two web professionals, supposedly knowledgeable in accessibility, thought that the HTML5 Summary element (together with the Details element) can be used in place of the summary attribute. This is wrong. The Details/Summary elements are not related to the summary attribute and data tables.

And if you’re wondering, the Details/Summary elements are HTML5’s solution to toggle functionality. Browser support for Details/Summary is not quite there yet.

The ARIA Alternative

A description of a data table isn’t needed (and therefore a summary attribute) if the table is simple and clear (one header level, succinct header text, caption provided, etc.). If a description is needed, the text should be placed in the main content itself. This text can then also be associated to the table with ARIA.

In the HTML 5.1 Nightly, you’ll see the ARIA technique, 4.9.1.1 Techniques for describing tables. (Also in HTML5 technique 4.9.1.1) This is the proper way to use ARIA in place of the summary attribute to describe a data table.

Addendum: Thanks to @DBoudreau for pointing out the the tabindex=0 is required at this time for this to work properly for all screen readers.

<p id="tblDesc">The following table displays student population data of Foobar High School between 2003 and 2011 as computed by the XYZ Corporation.</p>
<table aria-describedby="tblDesc" tabindex="0">
 <caption>Student Population of Foobar</caption>
 <thead>
  <tr>
   <th>Year</th>
   <th>Population</th>
   <th>Change</th>
  </tr>
 </thead>
 <tbody>
  <tr>
   <td>2003</td>
   <td>846</td>
   <td>-3</td>
  <tr>
   <td>2004</td>
   <td>855</td>
   <td>+9</td>
  </tr>
 </tbody>
</table>
Categories
conference csun review

CSUN14 Review

Another CSUN conference has come and gone, and they only get better each year. Of course I’m referring to the CSUN (California State University, Northridge) Annual International Technology and Persons with Disabilities Conference which happens at the incredible Manchester Grand Hyatt Hotel in downtown San Diego, California.

The conference was officially kicked off Tuesday evening with a keynote speech by Tommy Edison (starts at 9:45) who is also well known as the @BlindFilmCritic.

Tommy Edison
Tommy Edison, standing at the podium, presents the keynote address at CSUN14.

Events & Happenings

Besides the plethora of sessions to attend, many events (official and unofficial) and fun things were going on:

Highlighted Sessions

There are too many great sessions to note, but here’s are several to get you started:

Summary Next Year’s 30th

Next year is the 30th CSUN and promises to be even bigger and better than ever. Seriously, there are tremendous plans for CSUN15 are already under way. Hope to see you there!

More Resources

Categories
screenreader

Detecting Screen Readers – No

There has been much discussion about the idea of detecting a screen reader from a website and optimizing the code. In the W3C editor’s draft IndieUI 1.0: User Context, screen reader detection is proposed. This scares me and many others in the web accessibility community.

In the recent publishing of the WebAIM screen reader survey, one of the questions is “How comfortable would you be with allowing web sites to detect whether you are using a screen reader?”. Surprisingly 54% of respondents replied “Very comfortable”. This sure sparked some discussion on Twitter and on blogs.

For the most part, detecting a screen reader has been ill-received from the accessibility community. I am also strongly opposed to this idea.

The reasoning boils down to two issues: development and privacy. And it’s bad for both. Here are some reasons why it’d be bad for development:

  • Text-only websites didn’t work before and you know devs will do this if a mechanism is provided.
  • Screen reader detection is eerily similar to the browser-sniffing technique which has proven to be a poor practice.
  • Maintaining separate channels of code is a nightmare; developers overloaded already with supporting multiple browsers, devices, etc (via RWD). And if done, it will many times become outdated if not entirely forgotten about.
  • Why screen reader detection? If you follow that logic, then detection should be provided for screen magnifiers, braille output devices, onscreen keyboards, voice-recognition, etc. That’s just a bad idea.

Let’s hope screen reader detection is removed from the W3C draft of IndieUI 1.0: User Context.

PS: Interestingly, @LFLegal recently announced that Safeway is (finally) removing a text-only version of its website in the blog Separate is Not Equal: Good News for Grocery Delivery.

Further reading:

Updated August 2023