Accessibility

In this approximately 14-minute podcast, Allison Hilliker and Darrell Shandrow demonstrate the DropVox voice memo recording app for iOS.

This show features a special surprise musical treat sung by Allison!

• Listen or Pause – DropVox Demonstration
• Download – DropVox Demonstration

We love hearing from our listeners! Please feel free to talk with us in the comments. What do you like? How could we make the show better? What topics would you like us to cover on future shows?

If you use Twitter, let’s get connected! Please follow Allison (AlliTalk) and Darrell.

I recently ran into a problem that was really hard to figure out. I was working on a responsive design where I used img {max-width:100%;} to make sure that images would be downsized rather than overflow in narrower viewports.

It worked great everywhere… until I went to check in IE8. The site’s logo was gone! None of the usual IE bug fixes cured the problem, and it took me quite a while to realise that max-width was part of the problem.

Read full post

Posted in Browsers, CSS.

Copyright © Roger Johansson

In this approximately 30-minute show, Allison Hilliker and Darrell Shandrow demonstrate searching for, subscribing to and playing podcasts using the Downcast app for iOS.

• Listen or Pause – Downcast Demonstration
• Download – Downcast Demonstration

Downcast allows anyone with an iOS device to independently enjoy podcasts without having to connect to a computer and use iTunes to subscribe and synchronize the content.

All instructions assume VoiceOver is running on the iOS device.

Searching for Podcasts by Category

Follow these steps to browse and review podcasts by category. We use This Week in Tech as an example of a good technology show to consider adding.

1. Make sure the Downcast app is open.
2. Touch the bottom left corner of the screen to locate the Podcasts tab.
3. Right flick twice and double tap the Add Podcasts tab.
4. Tap the top of the screen once with four fingers to move to the upper left corner.
5. Right flick to and double tap the Technology category.
6. Right flick to and double tap This Week in Tech – MP3 Edition.
7. Right flick to and double tap View Podcast Feed. Note the Subscribe button and other information available as you right flick across this screen.
8. Right flick across the list of available podcast episodes and double tap one to start listening.
9. Double tap with two fingers to pause playback.

Search for Podcasts Using Keywords

Follow these steps to search for podcasts by keyword. We like books, so that’s our keyword search example.

1. If you were playing a podcast, double tap the Back button three times or use the two-finger right-to-left scrub gesture three times to return to the Add Podcasts screen.
2. Right flick to and double tap Search for Podcasts.
3. Type books into the search field.
4. Double tap the Search button in the lower right corner of the screen.
5. Tap the top of the screen once with four fingers to move to the upper left corner.
6. Right flick to and double tap the Books on the Nightstand podcast in the list of search results.
7. Right flick to and double tap the Subscribe button to add this podcast to your favorites.
8. Double tap the Back button twice or use the two-finger right-to-left scrub gesture twice to return to the Add Podcasts screen.

When the podcast you want is not in Downcast’s directory, there are three ways to bring it into the app. We did not cover these advanced topics on the audio portion of our show.

Adding Podcasts from a Link on a Website

If a website has a link to an RSS feed for a podcast, you can browse to it using Safari on your iOS device and easily add it to Downcast by following these instructions. The podcast page on the GW Micro website serves as our example.

1. Open Safari on your iOS device.
2. Visit http://gwmicro.com/podcast
3. Right flick to and double tap and hold on the link to the GW Micro – GW Insider Podcast Feed (XML).
4. Right flick to and double tap the Copy button. This makes the link available to other apps such as Downcast.
5. Open Downcast.
6. Touch the bottom left corner of the screen to locate the Podcasts tab.
7. Right flick twice and double tap the Add Podcasts tab.
8. Tap the top of the screen once with four fingers to move to the upper left corner.
9. Right flick to and double tap Add Podcast Manually.
10. Right flick to and double tap the text edit field after the Feed or OPML Address heading.
11. Select “Edit” using the rotor VoiceOver gesture.
12. Flick down and double tap Paste. The URL copied from Safari now appears in the text edit field.
13. If needed, enter the username and password under the Login Information, If Required heading. This will rarely be used. It is not needed for GW Micro podcasts.
14. Find and double tap the Done button in the lower right corner of the screen.
15. Tap the top of the screen once with four fingers to move to the upper left corner.
16. Right flick to and double tap the Subscribe button to add the podcast.
17. Double tap the Back button twice or use the two-finger right-to-left scrub gesture twice to return to the Add Podcasts screen.

Manually Adding Podcasts

Follow these steps when you know the URL of the RSS feed for the podcast you wish to add.

1. If a Back button can be found near the upper left corner of the screen, double tap it as many times as necessary or use the two-finger right-to-left scrub gesture as many times as necessary to return to the app’s main screen. This will typically be Podcasts, Playlists, Add Podcasts or Downloads.
2. Touch the bottom left corner of the screen to locate the Podcasts tab.
3. Right flick twice and double tap the Add Podcasts tab.
4. Tap the top of the screen once with four fingers to move to the upper left corner.
5. Right flick to and double tap Add Podcast Manually.
6. Right flick to and double tap the text edit field after the Feed or OPML Address heading.
7. Enter the URL of the RSS feed exactly as it was given to you. Leave off the “http://” at the beginning.
8. If needed, enter the username and password under the Login Information, If Required heading. This will rarely be used.
9. Find and double tap the Done button in the lower right corner of the screen.
10. Tap the top of the screen once with four fingers to move to the upper left corner.
11. Right flick to and double tap the Subscribe button to add the podcast.
12. Double tap the Back button twice or use the two-finger right-to-left scrub gesture twice to return to the Add Podcasts screen.

Adding Podcasts from an OPML File

Downcast can use OPML files to backup and restore the list of subscribed podcasts. This technique also allows users to bring in lists of podcasts from other apps and to share favorite podcasts.

Follow these steps to import a list of podcasts from an email.

1. Open the Mail app on your iOS device.
2. Open the email containing the OPML file attachment.
3. Right flick through the message until you reach the name of the file. This may be something like podcasts.opml.
4. Double tap the file’s name to open the attachment.
5. Right flick to and double tap the Action button.
6. Double tap Open in Downcast. The app will start dinging as it downloads the new podcasts.
7. Double tap the Podcasts tab in the lower left corner of the screen to see the revised list of subscribed podcasts including those just added from the OPML file. Beware: Downcast imports everything found in the file without checking for duplicate entries.

Playing Podcasts

Now that you have subscribed to several podcasts, you’re probably anxious to start listening to them. Follow these instructions to get started.

1. Double tap the Podcasts tab in the lower left corner of the screen.
2. Right flick across the list of subscribed podcasts until you reach the show you would like to hear.
3. Double tap the podcast to bring up the list of episodes.
4. Right flick to and double tap an episode to start playing the audio. Each episode has two entries in the list. The first allows you to download or stream the audio and the second provides details. Double tap download or stream links to play podcast episodes.
• The two-finger double tap gesture plays and pauses audio.
• The Play button is found in the middle of the bottom third of the screen. It changes to a Pause button while audio is playing.
• The Reverse button is located to the left of the Play button. Double tap it to move to the previous episode. Double tap and hold it to rewind in the currently playing episode.
• The Forward button is located to the right of the Play button. Double tap it to move to the next episode. Double tap and hold it to fast forward within the currently playing episode.

There are many more features available in the podcast playback screen. For instance, we demonstrated the ability to increase playback speed in the audio portion of our show. We urge you to listen to the entire demo, get the app for yourself, explore and start enjoying podcast listening on your iOS device.

Additional Resources

• TechAccess Daily Tip 239: DownCast
• Follow Downcast (downcastapp) on Twitter.
• Downcast Website

Please feel free to give us your feedback in the comments. What do you like? How could we make the show better? What topics would you like us to cover on future shows?

If you use Twitter, let’s get connected! Please follow Allison (AlliTalk) and Darrell.

The Web Content Accessibility Guidelines 2.0 became a W3C Recommendation (code for “finalized specification”) in December 2008. I am proud to have my name listed as a contributor to WCAG 2.0. All of WebAIM’s current clients are working toward WCAG conformance. None of them are seriously considering the antiquated Section 508, the update of which is perpetually stuck in bureaucratic delay tactics.

While WCAG 2.0 has been used to greatly enhance the accessibility of web content, it is not perfect. Its complexity and rather absurd terminologies, while generally necessary, decrease its approachability (and arguably accessibility) for many people. It is difficult to understand, something ironic considering that “Understandable” is a core principle of WCAG itself. WebAIM has provided a simplified WCAG checklist to help authors get started and to aid in evaluation. Accessibility and technology continues to evolve, and accessibility guidelines must evolve with them.

After three years of implementing and explaining WCAG 2.0, we have identified areas of the guidelines that could be improved or clarified. For a number of reasons, we are unable to participate formally in W3C processes, and we are unaware of any current plans for a WCAG 2.1 or a WCAG 3.0, so we present here some possible changes and improvements to WCAG 2.0, and items that we hope might help you better understand and implement optimal accessibility.

Remove the CAPTCHA Exception

Success Criterion (SC) 1.1.1 (Non-text Content) allows an exception for CAPTCHA, as long as it is identified as being a CAPTCHA and “alternative forms of CAPTCHA using output modes for different types of sensory perception are provided.” If a site provides both a graphical and an audio CAPTCHA, it passes. This, however, continues to exclude users that are deaf-blind, not to mention the difficulties that all users have with CAPTCHAs.

CAPTCHA has failed. Automated processes can now bypass it faster and more accurately than actual users. WebAIM clients, even those in the highly secure financial services industry, are abandoning CAPTCHA. WCAG should do the same by removing it as an exception, or perhaps allowing graphical and audio CAPTCHA for Level A conformance but prohibiting all CAPTCHA at Level AA.

Media Guidelines “Media alternative for text”

Several of WCAG 2.0′s media guidelines include “…except when the media is a media alternative for text and is clearly labeled as such.” This means that text alternatives are not required if the video is an alternative version of the main text content of the same page (for example, a web page with the text of a speech that also presents a video version of that speech). This, however, is often misunderstood to suggest that if a transcript is provided, then captions or audio descriptions are not required. This could perhaps be clarified to indicate that if the main content of the page provides all necessary content of the associated media, then no other requirements (captioning, transcript, etc.) are necessary.

“Alternative for time-based media”

“Alternative for time-based media” is a confusing term for a descriptive transcript – a text transcript of the audio or video that provides all necessary auditory content (such as identifying laughter or an off-screen explosion) and visual content (such as a list of items displayed in the video that are not presented via audio). We simply use “descriptive transcript” instead and have found is much more easily explained and understood. If a user reads the descriptive transcript, they will get all of the necessary content conveyed in the audio or video.

Audio descriptions and transcripts

Synchronized captions are always required for audio/video content at Level A. Additionally, either audio descriptions (auditory presentation of visual content in the video) or a descriptive transcript is required for Level A conformance by Success Criterion (SC) 1.2.3. Either of these meets the needs of users with visual disabilities. If an author provides a descriptive transcript to satisfy SC 1.2.3, then audio descriptions are required in SC 1.2.5 at Level AA. However, if an author provides audio descriptions to satisfy SC 1.2.3, then a descriptive transcript is not required until SC 1.2.8 at Level AAA. This latter case would render the media inaccessible to deaf-blind users at Level AA, because both captions and audio descriptions are inaccessible to these (and many other) users.

This is all compounded by the fact that if the video does not require audio descriptions (meaning all necessary visual content is presented in the audio of the multimedia), then SC 1.2.3 and SC 1.2.5 are satisfied. This means that for such video (e.g., a talking head), the author is not required to provide a descriptive transcript unless they are seeking Level AAA conformance. In other words, if a page contains only audio, it requires a descriptive transcript at Level A. But if you add a talking head video or simply add the audio to some video content, it doesn’t require a descriptive transcript until Level AAA. This surely is a weakness in WCAG 2.0 that should be addressed.

Recommended restructuring

Confusion and limitations of the current guidelines could be addressed by structuring the guidelines as follows based on the media’s characteristics:

• Level A
  • Pre-recorded audio only – provide descriptive transcript.
  • Pre-recorded video only – provide descriptive transcript or audio description.
  • Pre-recorded audio/video:
    • Provide synchronized captions.
    • If visual content is not presented via audio, provide audio description or a descriptive transcript.
• Level AA
  • Pre-recorded audio/video – provide a descriptive transcript.
  • Live audio/video – provide synchronized captions.
• Level AAA
  • Pre-recorded audio/video – provide audio description, if necessary.
  • Pre-recorded audio or audio/video – provide sign language.
  • Live audio – provide synchronized captions.

This structuring would require audio descriptions or a transcript at Level A, but only if they are necessary for blind accessibility. At Level AA, all pre-recorded video would require transcripts. At Level AAA, video would require audio descriptions, if they are necessary due to visual-only content.

It is with great hesitation that I recommend moving audio descriptions to Level AAA (in WCAG 1.0, they were Level A). While they are the primary and preferred mechanism for providing multimedia accessibility to users with visual disabilities, one must balance their significant expense and difficultly to generate and the fact that transcripts provide equivalent content and are also accessible to a much broader audience (e.g., deaf-blind). Because a transcript will already have been generated in order to provide captioning, it seems more logical that the emphasis should be placed on providing a nearly universally accessible descriptive transcript, rather than on providing less usable and more burdensome audio descriptions.

Contrast at Level A

White text on a white background is Level A conformant. No contrast requirements are present until SC 1.4.3 at Level AA. Adding a minimal contrast requirement (perhaps 2:1 and 3:1 for large text) at Level A would help address significant readability issues that could be found on Level A conformant sites.

Decrease the 200% Text Resizing Requirement

Users with significant low vision rarely resize text in a browser. If a user requires text that is twice the default size, page zoom or a dedicated screen enlarger is and must be used. Designing modern web interfaces to support 200% text resizing is very difficult. This Level AA success criterion typically poses the most significant burden to our clients (often more so than captioning). We strongly recommend that the text resizing threshold be reduced to 150%, with perhaps a 200% threshold for Level AAA conformance.

Clarify Images of Text

Success criterion 1.4.5 requires that if the same visual presentation can be made using text alone, an image is not used to present that text. The possibility of highly stylizing text and page elements with CSS (especially CSS3) begs the question of how one defines “same visual presentation”. For example, a graphical button with rounded corners, a background gradient, and text drop-shadow could be recreated with text and CSS3, but it is not clear if this is required to meet this Level AA success criterion.

While using text is always optimal for accessibility (and for other reasons), Level AA conformance should only require that the graphical text be replaced with true text when readily-available font face styling will suffice. In other words, authors should not be required to implement significant text styling to duplicate the graphical text’s presentation. SC 1.4.9 (Level AAA) already prohibits all presentation of text within images.

Specify Mechanisms to Bypass Blocks

A wide variety of “mechanisms” are available to allow users to bypass blocks of repeated content on web pages. This success criterion would be more meaningful and understandable if it required at least two possible mechanisms, such as:

• a “skip” link
• a consistent heading structure (e.g., main content always begins with an <h1>)
• in-page navigation links
• use of landmark roles
• HTML5 structural elements

“Can Be Programmatically Determined”

WCAG 2.0 uses the phrase “can be programmatically determined” extensively. A wonderful article by Jason Kiss explains this term and its use in WCAG. This term refers to relationships that assistive technologies can make between content and/or markup. WCAG defines it to mean that technologies “can extract and present this information to users in different modalities”, whatever that means.

In most cases, when WCAG 2.0 requires that something “can be programmatically determined”, modern technology can actually do so. But not always.

As an example, if an ambiguous “click here” link is preceded by a descriptive heading, this is allowable at Level A by SC 2.4.4 because the meaning of the link “can be programmatically determined” based on the heading structure. The problem, however, is the word “can”. No modern assistive technology actually implements a method whereby the link is automatically made unambiguous because of this structural relationship. In other words “can be programmatically determined” does not mean “IS programmatically determined”.

This creates a situation where WCAG allows or requires something that does not actually result in any better accessibility. It also presents a situation whereby authors can’t know for sure if their content is actually conformant without knowing if assistive technology CAN do something. And which specific technologies or how many of them must do it before “can” means “can”? This is very akin to WCAG 1.0′s very confusing phrase “until user agents…”.

While supporting documentation attempts to clarify this, it remains a confusing aspect of page conformance. This could perhaps be addressed by more specific details at the success criteria or techniques level that reflect actual assistive technology capabilities, rather than simply suggesting that potential support is sufficient.

Require Keyboard Focus Indicators at Level A

A lack of keyboard focus indicators for navigable page elements – SC 2.4.7 (Level AA) – renders a page nearly entirely inaccessible for the large population of sighted keyboard-only users. This is one of the most significant and pervasive accessibility issues currently on the web (see The Plague of Outline:0). There is no reason why this should not be a Level A requirement.

Remove Parsing Requirement

While the intentions are noble, SC 4.1.1 (Level A), which requires that significant coding validation errors be avoided, has little impact on end-user accessibility and is next to impossible to evaluate. The areas in which coding errors impact accessibility are already sufficiently covered by other success criteria (such as proper form labeling, frame titles, table headers, etc.). I can’t think of a single instance where a significant coding issue would impact assistive technology specifically. The parsing requirement should be removed or perhaps changed to require strict validation at Level AAA.

Conclusion

This is not intended to be a criticism of WCAG 2.0. The web is clearly much more accessible because of these guidelines. As future updates to WCAG are considered, and as authors implement these guidelines today, these recommendations might provide some clarity and guidance, with the hope of making the web more accessible for all users. If you have feedback on these recommendations, or have thoughts of your own on WCAG, please comment below.

Thursday, March 1 is Adobe Day at the CSUN Conference. We’ve got five sessions lined up, all in Elizabeth C (2nd floor):

• Acrobat X, with Greg Pisocky and Pete De Vasto, 9:20am
• Accessible e-books with Adobe Digital Editions with Kiran Kaja, 10:40am
• HTML Accessibility with Adobe Software with Michael Jordan and Matt May, 12pm
• Video and CVAA Compliance with Adobe Tools with Andrew Kirkpatrick, 3:10pm
• Adobe Town Hall with the whole Adobe Accessibility team, 4:20pm

There’s more to come. (Probably involving hors d’oeuvres.) But for now, mark your calendars, and we’ll see you in San Diego.

The Assistive Technology Industry Association’s annual conference, ATIA 2012, will be in full swing tomorrow, and our own Greg Pisocky will be appearing in three sessions:

• “Implementing ISO 14289 (PDF/UA)”, Thursday, January 26 8:00 am to 9:00 am Caribbean 6
• “eBook Accessibility with Adobe Digital Editions and EPUB”, Thursday, January 26 4:00 pm to 5:00 pm Curacao 3 – 4
• “Creating Accessible Documents More Efficiently with Adobe InDesign CS5.5”, Friday January 27 9:20 am to 10:20 am, Caribbean 3 and 4

That’s just the first outing of the year. In February, Adobe will be presenting at Techshare India, the 6th European eAccessibility Forum, and the CSUN Conference. We’ll keep you updated with sessions and times.

Adobe InDesign CS5.5 added a number of new features to make the accessible production of complex documents easier. Now the InDesign team has added an Action for use with Adobe Acrobat X. Once you install it, the Action will walk you through the most common steps for polishing up InDesign documents, including setting a document language, running Acrobat’s accessibility checker, and outputting an optimized, tagged PDF. The InDesign site has all the info, and the InDesign Action for Acrobat X can be found here.

Support for Digital Editions with assistive technologies continues to improve and this update is a tip for users of the Window-Eyes screen reader.

GW Micro has published an app designed to provide support for Digital Editions 1.8.1 that’s comparable to the support provided by other screen readers including JAWS, VoiceOver and NVDA. From the Window-Eyes Control Panel, Press ALT-A to get to the App Menu, and select AppGet. When the list of available apps is displayed, You’ll find Digital Editions in the “Program Enhancements” group.

Digital Editions 1.8.1 can be found at:

http://labs.adobe.com/technologies/digitaleditions1-8/

Comments are welcome as always.

Authors looking for additional guidance on how to meet the W3C WCAG 2.0 for PDF documents can now look to the W3C techniques repository for additional guidance. Techniques for PDF authored over the past two years since the release of the last update to the WCAG techniques (which included techniques for Flash) are now part of the larger collection of techniques. View the full set of WCAG 2.0 techniques or view PDF techniques on their own.

These techniques provide a clear path for demonstrating that a PDF document can meet the most current accessibility standard from the W3C.

As with the Flash techniques for WCAG 2.0 and techniques for all other technologies, the PDF techniques are presented as examples which the WCAG Working Group viewed as sufficient to meet WCAG 2.0 success criteria, not as the only way to meet any given success criteria. Authors may discover a new way to address a success criteria, in a way not yet covered in the existing techniques, and be able to demonstrate why it is sufficient. The techniques offer a collection of strategies that have been reviewed by the working group, but the techniques collections for all technologies are works in progress as there are always additional ways to address success criteria.

The table below provides a listing of the WCAG level A and AA success criteria and the PDF-specific and General techniques that authors can employ to meet success criteria. It is worth noting that not all success criteria for WCAG 2.0 have technology-specific techniques. For example 1.3.3 (Sensory characteristics) has only general techniques, and in this case and similar ones I reference the relevant general techniques section. In some cases there are relevant general techniques as well as PDF-specific techniques and for these both are linked.

Update: I neglected to acknowledge the hard work of Mary Utt from The Paciello Group on the PDF techniques initially, but Mary was a tremendous help in moving this work forward and I offer many thanks. Many people on the WCAG working group also worked very hard to help make these techniques reach this final stage. Thanks to all!

Please send general comments, comments or questions on the techniques, or suggestions for new techniques.

WCAG 2.0 Success Criteria and Applicable Techniques for PDF Success Criteria Level Techniques 1.1.1 Non-text Content A

• PDF1
• PDF4

1.2.1 Audio-only and Video-only (Prerecorded) A

• General Techniques: http://www.w3.org/WAI/WCAG20/quickref/#qr-media-equiv-av-only-alt

1.2.2 Captions (Prerecorded) A

• General Techniques: http://www.w3.org/WAI/WCAG20/quickref/#qr-media-equiv-captions

1.2.3 Audio Description or Media Alternative (Prerecorded) A

•  General Techniques: http://www.w3.org/WAI/WCAG20/quickref/#qr-media-equiv-audio-desc

1.2.4 Captions (Live) AA

• General Techniques: http://www.w3.org/WAI/WCAG20/quickref/#qr-media-equiv-real-time-captions

1.2.5 Audio Description (Prerecorded) AA

•  General Techniques: http://www.w3.org/WAI/WCAG20/quickref/#qr-media-equiv-audio-desc-only

1.3.1 Info and Relationships A

• PDF6
• PDF9
• PDF10
• PDF11
• PDF12
• PDF17
• PDF20
• PDF21

1.3.2 Meaningful Sequence A

• PDF3

1.3.3 Sensory Characteristics A

• General Techniques: http://www.w3.org/WAI/WCAG20/quickref/#qr-content-structure-separation-understanding

1.4.1 Use of Color A

• General Techniques: http://www.w3.org/WAI/WCAG20/quickref/#qr-visual-audio-contrast-without-color

1.4.2 Audio Control A

• General Techniques: http://www.w3.org/WAI/WCAG20/quickref/#qr-visual-audio-contrast-dis-audio

1.4.3 Contrast (Minimum) AA

• General Techniques: http://www.w3.org/WAI/WCAG20/quickref/#qr-visual-audio-contrast-contrast

1.4.4 Resize text AA

• G142

1.4.5 Images of text AA

• PDF7
• General Techniques: http://www.w3.org/WAI/WCAG20/quickref/#qr-visual-audio-contrast-text-presentation

2.1.1 Keyboard A

• PDF3
• PDF11
• PDF23

2.1.2 No Keyboard Trap A

• G21

2.2.1 Timing Adjustable A

• PDF3
• G133

2.2.2 Pause, Stop, Hide A

• General Techniques: http://www.w3.org/WAI/WCAG20/quickref/#qr-time-limits-pause

2.3.1 Three Flashes or Below Threshold A

• General Techniques: http://www.w3.org/WAI/WCAG20/quickref/#qr-seizure-does-not-violate

2.4.1 Bypass Blocks A

• PDF9
• General Techniques: http://www.w3.org/WAI/WCAG20/quickref/#qr-navigation-mechanisms-skip

2.4.2 Page Titled A

• PDF18

2.4.3 Focus Order A

• PDF3

2.4.4 Link Purpose (In Context) A

• PDF11
• PDF13

2.4.5 Multiple ways AA

• PDF2
• General Techniques: http://www.w3.org/WAI/WCAG20/quickref/#qr-navigation-mechanisms-mult-loc

2.4.6 Headings and Labels AA

• General Techniques: http://www.w3.org/WAI/WCAG20/quickref/#qr-navigation-mechanisms-descriptive

2.4.7 Focus Visible AA

• G149
• G165
• G195

3.1.1 Language of page A

• PDF16
• PDF19

3.1.2 Language of parts AA

• PDF19

3.2.1 On Focus A

• General Techniques: http://www.w3.org/WAI/WCAG20/quickref/#qr-consistent-behavior-receive-focus

3.2.2 On Input A

• PDF15

3.2.3 Consistent Navigation AA

• PDF14
• PDF17
• G61

3.2.4 Consistent Identification AA

• General Techniques: http://www.w3.org/WAI/WCAG20/quickref/#qr-consistent-behavior-consistent-functionality

3.3.1 Error Identification A

• PDF5
• PDF22

3.3.2 Labels or Instructions A

• PDF5
• PDF10

3.3.3 Error Suggestion AA

• PDF5
• PDF22

3.3.4 Error Prevention (Legal, Financial, Data) AA

• General Techniques: http://www.w3.org/WAI/WCAG20/quickref/#qr-minimize-error-reversible

4.1.1 Parsing A

• Not Applicable: PDF is not implemented using markup languages

4.1.2 Name, Role, Value A

• PDF10
• PDF12

In this approximately 27-minute podcast, Allison Hilliker and Darrell Shandrow demonstrate finding, downloading and reading with Bookshare’s Read2Go iOS app for the iPad, iPhone and iPod Touch.

We demonstrate reading with Read2Go’s built-in text-to-speech voices and VoiceOver while explaining the process in our typical step-by-step format.

Please feel free to give us your feedback in the comments. What do you like? How could we make the show better? What topics would you like us to cover on future shows?

Listen or Pause – Read2Go Demonstration

Download – Read2Go Demonstration

In March we released a closed captioning pod for Adobe Connect 8, and now we have a new version with additional features. Version 1.5 of the Connect Captioning Pod is available for free download.

This version still has all of the features available in the earlier version, but the new version also introduces the following features:

• Additional preset for caption providers using Streamtext. Streamtext provides an online caption delivery service utilized by hundreds of real-time captioners in North America and Europe.
• Support for word-by-word caption delivery and caption correction. End users can receive captions as they are entered by the stenocaptioner rather than waiting for a full line of captions to be delivered. Stenocaptioners also have the ability to correct mistakes in the captions by backspacing to delete errors and retype the correction. This feature is an option for the caption provider – at present Streamtext and CaptionFirst support this feature.
• Support for in-meeting captioners. Sometimes a meeting is scheduled when a stenocaptioner is not available, or budget doesn’t allow the hiring of a professional. For these situations, it is now possible to assign a participant the role of captioner. The captioner’s work will be viewed in the caption pod and can be exported to text or HTML and is archived as part of recorded sessions just like captions delivered by stenocaptioners. In-meeting captioners are less expensive but also typically deliver less high-quality captions for end-users. If experimenting with in-meeting captioners, make sure to ask end-users who need captions how effective the results are.
• Updated documentation for caption provider implementation is provided in the download package. Any caption service can deliver captions to Adobe Connect’s caption pod with this information.

Some images of the new pod:

As with the last version of this pod, development work was done by eSyncTraining, and we hope that you are as pleased with the results as we are!

The new pod, and documentation for incorporating it into your Connect meeting, is available now: Connect Captioning Pod v1.5 at the Adobe Connect Exchange.

In an ideal world there would always be a clean way of displaying data supplied by a third party on your site. Two examples would be getting the data in JSON or XML format from a Web Service and having an API to code against. But you don’t always have any of those options.

Sometimes the only way of incorporating data from a third party is by loading it in an iframe element. A few examples are financial reports, e-commerce applications, and ticket booking applications. Using an iframe is not ideal for many reasons, one of which is that it can make multiple sets of scrollbars appear on the page. Not only does it look ugly, it also makes the site less user-friendly. But there is a workaround.

Read full post

Posted in JavaScript, Usability.

Copyright © Roger Johansson

Showing whether a link on a web page has been visited or not can be very useful. One example that many will be familiar with is how it helps you know which links you have already followed from a Google search results page – links to pages you have already visited are a different colour than the other links.

Changing only the colour can be a bit subtle though, especially for people with colour vision deficiency. Depending on which colours are used to differentiate between visited and unvisited links it can be hard to tell them apart. To make the difference more obvious, there are a number of techniques involving background images, generated content (like the one I describe in Check marking visited links), and other CSS properties. However, if you’ve been using any similar tricks to style visited links, it’s time to forget about those and start relying on colour alone.

Read full post

Posted in Browsers, CSS.

Copyright © Roger Johansson

When adapting a layout for different viewport widths (a.k.a. responsive design) or media (like print), it’s common to reset any float and width values on major layout blocks to linearise their display.

Unfloating a floated element is as simple as specifying float:none. Width doesn’t seem to be quite as straightforward – lately I’ve come across several cases where people use width:100% to undo explicitly specified widths when they should be using width:auto instead. So here’s a brief explanation of the difference.

Read full post

Posted in CSS, Quick Tips.

Copyright © Roger Johansson

In this approximately 45-minute podcast, Allison Hilliker and Darrell Shandrow use the new iOS 5 VoiceOver custom-labeling feature to make the GetGlue social-entertainment iOS app accessible. Join us to learn about an exciting, useful iOS feature and have some fun along the way.

Custom Labeling Step-By-Step

1. Locate the unlabeled button by dragging your finger or flicking to it on the screen.
2. Double tap with two fingers and hold them in place. This is also known as a two-finger double-tap-and-hold gesture. You will hear three tones followed by “Alert, label element, text field, is editing.”
3. Type a short label for the button.
4. Locate and double tap the Save button. It can be found above the keyboard on the left side of the screen.

In addition to making the controls in an app accessible, the custom-labeling feature can be used to describe pictures in other contexts, such as the photos in your iPhone’s camera roll.

Allison asked an excellent question: Are custom labels backed up to iCloud or iTunes? Please feel free to answer in the comments.

GetGlue Information

GetGlue is a Foursquare-like social network for entertainment. It is available on smartphones and the Web. You can check into your favorite books, movies, music, TV shows and much more and share information about all the fun you’re having with your friends. The primary GetGlue.com website works best with browsers like Chrome, Firefox, Internet Explorer or Safari on computers. The mobile m.getglue.com website is intended for use with smartphones. It may be a more accessible alternative to the primary site for some computer users.

Tip from Allison: I recommend signing up on the GetGlue website before logging in with the iOS app.

There are two ways to get started:

• Sign Up with Facebook
• Sign Up with your Email Address

We’d Love To Hear From You!

Do you like the show? What would you like us to cover next? Please give us your feedback in the comments.

Listen or Pause – Custom Labeling Demo

Download – Custom Labeling Demo

I just recently ran into an issue when styling buttons that had me pulling my hair for a while. I had my buttons looking the way they were supposed to look in desktop browsers, but when I went to have a look in Safari for iOS, much of my CSS wasn’t applied.

This was pretty puzzling as I couldn’t remember having any problems with buttons in Safari for iOS before. After taking a closer look at the CSS I was using for these particular buttons and the CSS I had used previously, I managed to find out what made the difference.

Read full post

Posted in CSS.

Copyright © Roger Johansson

As I have noted in a couple of blog posts recently, there are some cases when CSS has quite unexpected results in screen readers (or the way web browsers create the accessibility information they hand over to screen readers). If you haven’t read them, the posts are Screen readers, list items and list-style:none and Using display:table has semantic effects in some screen readers.

Here are a few examples:

• Using display:table on non-table elements to get the visual layout characteristics of an HTML table without actually using one may cause screen readers to act as if there was a real table
• Using display:block or float on table-related elements may cause screen readers to treat the table as a layout table and ignore its semantics or report an incorrect data structure
• Using list-style:none to visually remove bullets or numbers from list items may cause screen readers to ignore them too, basically treating list items as paragraphs of text

Read full post

Posted in Accessibility, CSS.

Copyright © Roger Johansson

A new version of Adobe Digital Editions is available, and with it comes additional improvements for accessibility.

Users relying on VoiceOver, JAWS, or NVDA, and keyboard-only or high-contrast users can make use of this application to read electronic books, including books from booksellers such as Barnes and Noble and Waterstones, and books loaned via public libraries which use OverDrive for electronic book delivery.

In this release we’ve addressed several issues identified internally and externally, including the major enhancement request which was to enable continuous reading. We’ve also shared information with assistive technology vendors who have done significant work on their end to increase support for this application.

The installer is available at http://labs.adobe.com/technologies/digitaleditions1-8/. Of particular interest is the “Getting Started” book that is installed with the application, as this book details keyboard shortcuts and other information related to accessibility support.

I’m interested in any feedback that people may have on this release, as well as requests for future enhancements.

UPDATE 1/5/2012: Window-Eyes 7.x now supports Digital Editions 1.8.1 through a downloadable app. More information is available at the blog post announcing the availability of this app.

Back in the day you used to be able to view source on a web page to see the markup used to create it. These days, on many sites, a large portion of the markup is not visible when you view source because it is inserted by JavaScript functions.

That isn't necessarily a problem provided that you use progressive enhancement and unobtrusive JavaScript. If you follow those principles, content and basic functionality will still be there when scripting is unavailable. Many of us understand that. But one thing I’ve noticed is that some developers forget to consider semantics or accessibility in the markup they use JavaScript to insert.

Read full post

Posted in (X)HTML, Accessibility, JavaScript.

Copyright © Roger Johansson

I’ve always been wary of styling form elements too much. Possible usability and accessibility issues, browser quirks, and the fact that the CSS specification does not define form control styling are the main reasons.

With that said, sometimes you have to do things you don’t really want to. Like styling select elements, which I’ve recently had to find a way to do. There are quite a few workarounds for doing this out there. However, most of the ones I looked at replace the select element with a bunch of links which changes semantics and behaviour a bit too much for my tastes. I couldn’t find any implementation that I was completely happy with, so I took the best one I could find and tweaked it.

Read full post

Posted in Accessibility, CSS, JavaScript.

Copyright © Roger Johansson