#GAAD #a11y #BugBash Global Community Effort to Squash Accessibility Bugs

Celebrate Global Accessibility Awareness Day with Deque and the #a11y Community by helping file accessibility bug reports with assistive technology vendors and web browser developers.


The plan is to ask everyone involved in GAAD and #a11y on Twitter to file as many UA/AT accessibility related bugs as they can handle and post what bugs they’ve filed to the GAAD Bug Bash Google Spreadsheet Tracker.

#GAAD #a11y #BugBash Tracker


The GAAD Bug Tracker is a publicly editable Google Spreadsheet that should be accessible and available for anyone to add new bugs. So far I’ve listed column headers for what a typical bug report needs and typed in a few bugs that I’ll be filing personally :).

Work in Progress, Always Happy To Evolve

This is a community effort so please leave comments with suggestions or find me on twitter @pauljadam to provide feedback. Thanks!

So far the column headers I’ve listed are:

  1. Bug #
  2. Title
  3. Description
  4. Steps to Reproduce
  5. Expected Results
  6. Actual Results
  7. Screenshot
  8. Platform
  9. User Agent
  10. Assistive Technology
  11. Impact
  12. Status
  13. URL to Bug Report
  14. Bug Report ID#
  15. Bug Reported By
  16. Additional Notes

Where to File Bugs?

Now where would we file all these bugs to exactly? Well it depends on if it’s a browser (User Agent) bug or a screen reader/assistive technology bug. Not all UA/AT vendors have public bug trackers or any bug tracker but most do. Many of the bug trackers also have bug reporting guidelines to show you how to file a actionable bug report that we hope will actually get fixed one day 🙂

Current List of Bug Tracker Systems
Bug Tracker URL Details/Bug Reporting Guidelines Bug Type
Apple Bug Reporter http://bugreport.apple.com Screen Reader
Assistive Technology
Native iOS/OS X
Open Radar http://www.openradar.me Open radar is a way make your bug reports with Apple public as their tracker is not searchable. This does require you to file both with apple and with open radar (to let the world know). Screen Reader
Assistive Technology
Native iOS/OS X
Chromium bug tracker https://code.google.com/p/chromium/issues/list http://www.chromium.org/for-testers/bug-reporting-guidlines-for-the-mac-linux-builds Browser
Internet Explorer Feedback https://connect.microsoft.com/ie/ https://connect.microsoft.com/IE/content/content.aspx?ContentID=29582 Browser
Bugzilla@Mozilla https://bugzilla.mozilla.org https://developer.mozilla.org/en-US/docs/Mozilla/QA/Bug_writing_guidelines Browser
NVDA Issues http://community.nvda-project.org/wiki/Issues Screen Reader
Webkit bugzilla https://bugs.webkit.org/ https://bugs.webkit.org/page.cgi?id=bug-writing.html Browser
GNOME (Orca) Bugzilla https://bugzilla.gnome.org/enter_bug.cgi?product=orca Screen Reader

Steve Faulkner’s filing bugs tutorial

Duplicate Bug Reports

The issue of duplicate bug reports is a problem with non-public bug trackers like Apple’s. I’ve filed bug reports with apple only to find out they were duplicates but once you find that out there’s no actual way to search the bug tracker to read what the previous person’s bug report says. So you basically have to take them at their word that someone else really did file the same #a11y bug as you!

The community solution to Apple’s secrecy is www.openradar.me where you basically have to file a duplicate bug report to let the community know about the bug and ask them to promote it being fixed by duplicating the same issue into the official apple bug reporter.

Promoting Bug Reports or The Popularity of an Accessibility Bug

Some public bug trackers allow registered users to “Star” or Favorite an issue to hopefully get it more attention and fixed faster.

vote for issue

Vote for this issue and get email change notifications.

Another accessibility bug tracking project of note is the a11y bugs project, http://a11ybugs.org. Though it has not been updated in 2 years based on the last tweet. https://twitter.com/a11ybugs/status/358253366964523008

You can also search for “Accessibility” in the bug trackers to find a11y bugs already entered.

Please File Accessibility Bugs for #GAAD! Thanks!

Here is the bug tracker with all the info you need to fill out and links to the various bug reporting systems.

#GAAD #a11y #BugBash Tracker


Please make sure to report the bugs you’ve filed so others can duplicate them if they are serious issues or they just want to call more attention to Accessibility for GAAD.

Also please feel free to leave a comment on this post with the bug you filed or any other suggestions, questions, or comments.

The bugs can be filed starting now and on GAAD we’ll get them even more attention, star them, dupe them, tweet, and promote the issues caused by bugs in assistive technologies and browsers that do make accessibility more difficult and less “Global”.

CSUN 2015 Thursday Session Picks, Exhibit Hall, & 30th Anniversary Celebration #CSUN15

Here’s a list of #CSUN15 Thursday Sessions that I’m interested in and will try to attend. Don’t forget about the Exhibit Hall which is actually FREE to non-badge holders and Thursday night is also the CSUN 30th Anniversary Celebration & Reception.

Thursday, March 5, 2015

8:00 AM PST

9:00 AM PST

10:00 AM PST

11:00 AM PST

1:20 PM PST

2:20 PM PST

3:20 PM PST

 4:20 PM PST

Firefly, a $99 Fire Tablet & Latest in Amazon Device Accessibility

Exhibit Hall (Trade Show Floor) FREE!


Thursday and Friday hours are 9:30 am – 5:30 pm.

Exhibit Hall Only Attendee Registration, https://www.csun.edu/cod/conference/2015/sessions/index.php/public/exhibit_hall_registrations/add

Evening Events

30th Anniversary Celebration & Receptionhttp://www.csun.edu/cod/conference/2015/sessions/index.php/public/website_pages/view/4

Mark your calendars for Thursday, March 5 at 7:00 pm for this anniversary event. Please arrive early as, unfortunately, seating is limited and can only be accommodated on a first-come, first serve basis.




CSUN 2015 Wednesday Session Picks, Tips, & Parties #CSUN15

CSUN Session Tips

Double, triple, and/or quadruple book your session schedule calendar and make sure you arrive super early if you really want to get to see a certain session and get a good seat. Popular sessions with big names will be full based on previous year’s experience. I’ve had to miss sessions for not arriving early and they were too full.

Another reason to book 4-5 sessions for each time slot is that you may find that after arriving at a session  you’re not particularly interested in the topic or it’s was not what you were expecting from the title or description. Whatever your reason is, I would say just get up and leave QUIETLY, obviously be respectful, but don’t feel that you’re forced to sit through a session if you’d rather see if there’s something more interesting. You may even rather just chat and network with Accessibility professionals in the hallways or at the bar. I see people at SXSW bailing on sessions way more than I do at CSUN but I have done it myself many times bouncing from session to session just trying to find an interesting and new topic.

Sessions are only 40 minutes this year so dropping in and out may not be much of an option so plan to have your main top session for each hour and then have at least a 2nd fav and a 3rd possibly. It was not had for me to pick many sessions for each hour because there are so many to choose from and they’re all booked at the same time slots! This is always a problem at CSUN and there’s not much of a solution other than the Conference recording all sessions for viewing later. I guess with 20 minutes now between the start and end of each session there shouldn’t be many excuses for not arriving early to the talks you’re most interested in getting a good seat.

FYI some CSUN sessions are sponsored/paid in special sponsored session rooms, if that factors into your decision or not. Deciding CSUN sessions is a lot like SXSW Interactive, research the presenters, research the company, check on twitter, read blog posts, choose many options, go with many back up plans, OR JUST WING IT! Or just blow off sessions and network with a11y nerds! The conference is what you make it, don’t be shy if you see someone you want to say HI to or chat with as this may be your only chance of the year until CSUN16!

Sessions I’m Interested In

These are sessions I’m interested in either based on the title, the subject matter, or the author presenting.

Wednesday, March 4, 2015

9:00 AM PST

10:00 AM PST

11:00 AM PST

Dueling Mobile (This is my group session on Mobile Accessibility iOS VoiceOver vs. Android TalkBack so obviously the only one I can attend 🙂 Please Come!)

It sucks that there’s no way to see the sessions you also miss during your own presentation! Recordings would be AMAZING!!!

 1:20 PM PST

 2:20 PM PST

3:20 PM PST

Parties & Networking

The CSUN Newsletters have info about the parties and networking opportunities at the conference. Last Newsletter before Conference

Keynote Address & Welcome Reception
Please be sure to join us in the Seaport Ballroom on Tuesday evening, March 3 at 5:30 pm for the official opening of the 2015 Conference

Deque Reception and Sign Language Karaoke – Wednesday, March 4th!

If you’re reading this blog post then I am personally inviting you to our #DequeParty2015! 🙂 Please come and say hi, I’d love to chat about nerdy #A11y stuff!

By popular demand, Deque has decided to join forces with the Accessible Karaoke Party and get the party started early.

WEDNESDAY, MARCH 4th – 5-6:30pm – Join us in the EXHIBIT HALL for food, drinks, and to pick up a ticket for a special iWatch raffle.

6:30pm – Make your way to the PALM FOYER for heavy hors d’oeuvres, drinks, a special keynote speech from Ajit Narayanan, the presentation of the 2015 Amaze Award, TWO iWatch RAFFLES, and the Accessible Karaoke Party!

EVERYONE IS INVITED!  So don’t miss out!  Sign up at deque.com/csun2015! And tweet with hashtag #dequeparty2015 for an extra drink ticket!

Thursday, March 5, 2015

8:00 AM PST

I’ll start my next blog post with Thursday’s sessions 🙂

CSUN 2015 Tips & Tricks, #CSUN15 Survival List

Hey CSUN 2015 folks! Since this is my 4th year attending and presenting at CSUN I thought maybe I do have some tips & tricks I could suggest based on my limited experience. I also asked for some ideas from my wife Jackie who will be on her 3rd year now so she’s practically a pro as well.


There’s not much food I like that is within walking distance honestly. But the reality is you are going to be hungry and won’t have much time to spare if you don’t want to miss out on the conference action. FOMO, Fear of Missing Out, 😉 You need to read the Yelp reviews though, most places in walking distance are not good. I didn’t like the BBQ place across from the hotel, most of the food on-site inside the hotel will be crazy expensive but yes convenient. Convenience has its price at CSUN!

A few places in walking distance that I’ve eaten at multiple times and could recommend are:


Richard Walker’s Pancake House, http://www.yelp.com/biz/richard-walkers-pancake-house-san-diego

Richard walker’s is the best breakfast food I’ve had there and it’s very close to walk. They are only a usable option during the weekdays because on the weekend there is a line of like 100 or so people, I’m not kidding! Enjoy the ability to eat there during the boring weekdays I guess 🙂 That’s one of the nice things about CSUN being in the middle of the week because San Diego and the Gas Lamp area get very crowded during the weekends.

Skybound Coffee & Dessert Lounge, http://www.yelp.com/biz/skybound-coffee-and-dessert-lounge-san-diego

Skybound, I can’t really remember the name but I know them as the place on the corner across from Richard Walker’s, and also being the only place on a Saturday that you can actually get some breakfast from since there is a hundred people in line at Walker’s. It’s not amazing, it had good smoothies and bagels.

Both in walking distance very close to the Manchester Grand Hyatt.


Sally’s Seafood On The Water, http://sallyssandiego.com

Sally’s best feature it that it’s right out the back door of the Manchester so it’s a very easy place to meet folks after sessions or get lunch. It’s expensive though like most food and drinks in San Diego. Sally’s has a happy hour each day with food and drink specials though so that is a good affordable option very close to the action.


Ralph’s, https://www.ralphs.com/storeHours?store=70300123

Ralph’s is open 24 hours! It’s not really that far to walk either. If you don’t want to pay the big bucks for food, drinks, water, snacks, toiletries, etc. at the hotel then Ralph’s is the closest option I’ve found.

Hangout spots

On site at the Manchester


There are 2 restaurants/bars at the main floor of the Hyatt on the north west and east sides. Redfield’s Sports Bar and The Grand Lobby Bar. They are expensive but they are on site and they have food and beer and lots of places to sit so you will see lots of networking happening here.

The Top of the Hyatt is the late night spot and is the only spot with drinks open very late at the hotel. The drinks are very expensive but it’s a good spot to talk Accessibility with CSUN folks without leaving the hotel late at night.

Gas Lamp District

There are way too many places to list in the Gas Lamp District and I don’t really remember them all. The one place I do like to go for late night music and dancing is the Tipsy Crow 🙂 http://thetipsycrow.com/

Gas Lamp is the nightlife district and has many restaurants and bars to offer, there’s also a movie theater. It can get crowded with locals towards the end of the week. It’s a bit of a walk so you may or may not want to take a taxi. Might want to take it back late at night if you don’t want to walk back to the hotel. There’s always tons of taxi’s waiting outside of the hotel entrance.

Tourist things I’ve liked

We went to the beaches close by, Ocean Beach and Mission beach, and while the water was cold it was very clear and the sand was very clean and soft. Texas beaches have warmer water but the sand is not as pretty. Walk the Ocean Beach fishing pier and you can watch the surfers which is fun. I’d love to go fishing here one day but summertime is best for fishing is my thinking and no one was catching anything last year.

San Diego Zoo was amazing! The biggest zoo I’ve ever been to in my whole life I was very surprised, it’s hard to see the whole zoo in one day. Nothing like the zoo’s in Texas!

This year we’re just sticking around the hotel and the gas lamp district with no extra time for tourist things. San Diego is my favorite conference city other than Austin 🙂

Tips for next year

Because it’s too late if you already booked your hotel room but I still wanted to give out the advice for next year.

I hope you are staying at the Manchester Grand Hyatt because it’s nice to be able to take a break at you hotel room after lunch, between sessions, or before and evening full of networking.

Make sure to ask for a water view and not a city view because the first year I went I got stuck with a shady city view that also turns into a bad experience when the train goes off at night.

Jackie Adam’s CSUN Survival List

  • Dongle cable or whatever other cables are needed for your presentation. Bring extra if you’ve got some you might need to be the HERO if someone forgets it. But you don’t want to let someone borrow your only one!
  • Bring plenty of business cards it is an accessibility conference and you are sure to be networking all day everyday! You will need them!
  • Bring some aspirin part of networking might involve some heavy drinking! And a hangover !
  • Bring cash you just might need it!
  • Wear comfortable shoes goes without saying you will most Likely be walking around from place to place! Your feet will thank you!
  • Bring a jacket you never know the weather is surprisingly crazy if the sun comes out you can always diss the jacket but if you do need it you’ll be glad you brought it.
  • Bring some airborne you never know who’s mingling around with a cold and you want to stay as healthy as possible!
  • Wear any cool shirts related to accessibility or just plain cool in general they may lead to an interesting conversation!
  • Bring some nice/decent clothes in case you have to impress some clients or go to dinner at a fancy place.
  • Bring some gum, bad breath is not something you want someone to remember you by!
  • Bring your laptop/ phone charger or you will be completely lost! Duhhh!
  • And most importantly don’t forget your “Dancing Shoes”
  • That’s all I can think of for now! Hope it helps!

Other CSUN Tips & Tricks & Related Info Blog Posts

Hey #CSUN15 folks please come to #DequeParty2015 Wed after 1st day of sessions for food, drinks, music, karaoke #a11y http://deque.com/csun2015


WAI-ARIA role=alert on Static Warning Messages & Stopping VoiceOver for iOS from Speaking CSS Generated Content Icons with aria-hidden

Non-Disappearing Alert

Testing a client travel site I see a static weather travel alert warning that is very visually marked as important on the screen but the screen reader user would have no idea of its importance because there are no accessibility API semantics communicated.

screenshot of travel alert example

CSS Generated Icons Cause VoiceOver for iOS Bugs

There is also a CSS Generated Content glyph icon to indicate visually that this is a warning or error message. The text Travel Alert: is red and bold but it has no heading semantics.

I think the string “Travel Alert:” serves as the text alternative for the warning icon itself so you don’t need additional alt text.

VoiceOver for iOS has a bug or a feature, not sure, that causes it to speak “Face Screaming in Fear” when focused on this bootstrap CSS generated warning icon! That’s crazy right! 🙂 I’m serious go test it out. http://pauljadam.com/demos/role-alert.html

aria-hidden=true Prevents VoiceOver for iOS from Speaking CSS Generated Content Icons

Bootstrap code for this had aria-hidden=true already correctly applied to the span that generates the icon but I’ve seen this bug out in the wild on many client sites so glad to see the solution works! Try the before and after example.

voiceover displaying css generated icon but not speaking it

See Details Link Purpose Determinable?

Link Purpose is another issue where a screen reader user could not determine the purpose of the See Details link if they just TAB to the link and only hear “See Details, link”. What exactly are the details I’ll be seeing if I click the link? I recommend placing the aria-describedby attribute on the See Details link with a value that points to the ID reference of the full travel alert string text. This way the actual details text of the travel alert will serve as the accessible description in the a11y API.

Simple Heading with WAI-ARIA role=heading and aria-level=1

Travel Alert: to me serves as a heading that sections off a chunk of content below it so it needs semantics. I’m fine with not changing the HTML tag here and we can just apply role=heading and aria-level=1 to the <strong> element and BOOM it’s a heading! At least to the screen reader users and the a11y API 🙂

screenshot of VO OS X on the aria heading
VoiceOver reads “heading level 1, Travel Alert:

But can we put role=alert on static text alerts?

So we fixed the missing heading, we fixed the warning icon issue, fixed the link purpose issue… But I had this idea that this really could use even more semantics to help convey its importance because it does not pop up after page load or flash on the screen so there’s no ARIA Live Region because there’s no text being inserted or removed from the DOM.

The Mozilla Developer Network Using the alert role article is the first google result and gave me the idea based on example 1, https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_alert_role.

Example 1: Adding the role in the HTML code

The snippet below shows how the alert role is added directly into the html source code. The moment the element finishes loading the screen reader should be notified of the alert. If the element was already in the original source code when the page loaded, the screen reader will announce the error immediately after announcing the page title.

<h2 role="alert">Your form could not be submitted because of 3 validation errors.</h2>
Now this does not actually work to speak the alert text after the page loads. You MUST use JavaScript to inject a string into a role=alert container that was already present in the DOM on page load for it to actually speak out loud to the screen reader user! So if I removed the string then reinserted it after page load then it would speak, as long as the alert container itself was in the DOM on page load, just not the text. YES IT’S CONFUSING 😉

Results of role=alert on Static Text

So in our travel alert example I add the role=alert attribute/value to the entire alert container and there is NO MAGIC, except if you TAB into the See Details link in which case VoiceOver for OS X will now speak the contents of the alert container which sounds great! Even better because VO OS X does NOT read aria-describedby values by default except after a 7 second delay which is very confusing. This experiment solves that problem and also gives it some logical extra semantics.
TalkBack on Android likes alert roles and speaks the semantics like it’s a heading or some other semantic element.
role=alert on static text does nothing for VoiceOver on iOS but aria-describedby speaks with only a 2 second delay here in Mobile Safari so it sounds great without needing the alert role like OS X VO does.

Live Before & After Demo:


before screenshot
VoiceOver OS X says “visited, link, See Details”.


after screenshot
VoiceOver for OS X says “Travel Alert: Winter Storm Juno, Mid-Atlantic and Northeast United States. See Details, link, alert, visited, link See Details”

VoiceOver OS X “Help Text” or “Hints”:

help tag screenshot
If you wait 7 seconds or so VoiceOver for OS X says the aria-describedby value (also title attributes): “You are currently on a link, inside of HTML content. To click this link, press Control-Option-Space.  The help tag is:  Travel Alert: Winter Storm Juno, Mid-Atlantic and Northeast United States.”

After on Android in Firefox with TalkBack:

firefox android talkback screenshot
TalkBack/Firefox/Android speaks when focused on the After example Travel Alert: heading: “Travel Alert: heading level 1 alert”.
firefox android see details link screenshot
TalkBack speaks when focused on see details link: “See Details – Travel Alert: Winter Storm Juno, Mid-Atlantic and Northeast United States. See Details link”

Great Reasons for Accessibility Specialists to Have a Mac!

Here are some great reasons that you as an accessibility specialist, tester, developer, etc. should have a Mac for Accessibility Testing. You can provide these to your boss if they’re being cheap and think a shitty PC is “good enough”. Remember there are always plenty of other jobs out there that will let you use the computer operating system that you like and you’re most efficient on 🙂

  • OS X is required to do on-device iPhone/iPad HTML/DOM code inspection using the web inspector in Safari for OS X. This does NOT work with Safari for Windows!
  • With the mobile web inspector you can modify an ARIA property on the fly through the mobile safari browser and test the results with VoiceOver instantly.
  • OS X is required to install Xcode the Native iOS Integrated Development Environment (IDE). This comes with the iOS Simulator which also has an Accessibility Inspector that allows limited a11y testing.
  • Xcode also comes with the Accessibility Inspector an app separate from the iOS Simulator’s Inspector.
  • You can’t built native iOS apps to test accessibility remediation techniques unless you have Xcode for OS X.
  • You can’t test VoiceOver & Safari accessibility behind a VPN if you don’t have a Mac that has VPN access.
  • VoiceOver for OS X has a visual speech output caption panel that shows the text VO is speaking and makes for great screenshots to show developers the accessibility problem because they can see what VO is speaking.
  • Native Android accessibility testing/development can also be done on a Mac with Android Studio and Android Lint.
  • VoiceOver is a free screen reader with free updates and no licensing costs unlike JAWS.
  • Apple’s iWork Suite of Office Apps (Pages, Numbers, Keynote) are now mostly accessible with VoiceOver for OS X and iOS and they are FREE when buying  Mac or iOS device.
  • MS Office is NOT accessible, however, it is available for OS X and I do personally use MS Word, Excel and PowerPoint since I’m not reliant on VoiceOver and have used Office my whole life.
  • You can still create accessible PDF and Office Documents using MS Office and Adobe Acrobat on a Mac.

Please add more reasons in the Comments! 🙂

Include Accessibility in Your Company’s Style Guide – Part 1

It seems that style guides are meant to serve as good examples of Company-Endorsed HTML Code, CSS Usage, Brand Colors, Logo Usage, etc. Their purpose is also likely to train employees in standardized coding practices to make collaboration easier.

So why would your company want to actively promote inaccessible HTML coding methods that actually reduce customer usability of your website and forms?

The Style Guide is the PERFECT place to promote standards-compliant, accessible code and user-centered design/usability best practices!

In Part 1 of this series I’ll post a few inaccessible code examples from Yelp’s style guide which gave me the idea for this topic. 

Examining Style Guides from Web Companies

Stylibrary is a collection of style guides from big web companies like GitHub, Yelp, WordPress, jQuery, and more. Maybe it will be updated with more in the future, I’m sure there are lots of other big company’s style guides out there and I’m sure they have accessibility problems in the code samples. 

Stylibrary | A collection of front end style guides

Yelp recently made their front-end design and development style guide open to the public on their blog, Yelp Product & Engineering Blog: Yelp’s got style (and the guide to back it up). It looked interesting so I checked it out and did my accessibility nerd thing and went straight to examine the code to see if it was actually accessible. 

Styleguide | Yelp

Finding issues like bad color contrast does not surprise me in modern web libraries, e.g. gray on gray text, really light, hard to read gray text, etc. WCAG 2.0 AA color contrast violations are present and can easily be discovered with a contrast analyzing tool like Deque’s FireEyes. 

Forms Accessibility Failures Are More Disappointing

Forms are the first place to look and see if a company is following accessibility requirements. Yelp’s text input examples have label elements that are not connected to their inputs using the for/id construct. Their fieldset examples with radio buttons or checkboxes do not have legends to serve as the common label for the set. 

screenshot showing accessibility errors on labels

Jim Thatcher’s Favlets showing errors on the labels and inputs.

VO reading edit text Placeholder text

Since there is no connected label VoiceOver reads “edit text Placeholder text”.

Yelp’s Inaccessible Form Labels Code

<form class="yform">
<label>Label name</label>
<span class="help-inline">Optional</span>
<input type="text" placeholder="tacos, cheap dinner, Max's">
<label>Label name</label>
<span class="help-block">Optional. Yelper name or an email address.</span>
<textarea placeholder="Placeholder text"></textarea>
<input type="text" disabled="disabled" placeholder="Disabled placeholder text">

Yelp’s Form Labels Code Made Accessible

<form class="yform">
<label for="input1">Label name</label>
<span id="help1" class="help-inline">Optional</span>
<input type="text" id="input1" aria-describedby="help1" placeholder="tacos, cheap dinner, Max's">
<label for="input2">Label name</label>
<span id="help2" class="help-block">Optional. Yelper name or an email address.</span>
<textarea id="input2" aria-describedby="help2" placeholder="Placeholder text"></textarea>
<input type="text" aria-label="Invisible Label Name" disabled="disabled" placeholder="Disabled placeholder text">

In addition to not creating accessible names for a screen reader to speak to a blind user the form labels are also not “clickable”, that is, a mouse user cannot click on the label to put their input cursor into the text field and a mobile user cannot tap on the label to set focus to the input either. This is bad for usability! Our fat fingers need extra space to tap. 

Error Messages Not Programmatically Associated

VO reads edit text blank

Yelp’s form error messages are not spoken by screen readers in forms mode because the error text is not connected to the input. Instead VoiceOver for OS X is shown reading only “edit text blank”. 

Using WAI-ARIA this can be fixed easily like so:

<input type="text" aria-required="true" aria-invalid="true" aria-describedby="error" class="input-error">
<p id="error" class="text-error text-error-inline">Please provide a valid email address</p>

In Part 2 I’m likely going to use GitHub’s style guide for examples because they have TONS of problems with their forms!

Let me know what you think in the comments 🙂

Image & Text Inside a Link Accessibility Issues (Alt & Title Attribute, Expanded/Collapsed State, WAI-ARIA aria-expanded)

This blog post in inspired by the problem where developers have expandable/collapsable content usually in the form of a list of FAQ questions. The question has a +/- graphic that visually indicates to the user to click to expand and see the answer to each FAQ question.

Expanded/Collapsed State

So the accessibility problem is how do you indicate expanding/collapsing content to screen readers?

Another issues sometimes seen is that the developer will have two separate links, the image and the text. These should be combined into one link element for simplicity and to increase the click target area.

Options to Indicate Expanded/Collapsed State

Alt text on the image.
Title attribute on the link, null alt on image.
WAI-ARIA’s aria-expanded on link, null alt.
Visually hidden state text.

Alt on Image

My first thought is alt on the image that dynamically changes from expanded to collapsed using JavaScript. This would be the accessibility standards way of coding it.

Title on Link

Lots of folks like to use the title attribute to indicate things that are not visible in text. I think the title attribute is best used for screen magnification accessibility and possibly cognitive usability improvements. I don’t think the title attribute should be relied upon to communicate information. You’ll see one reason in the test cases.


Personally I love WAI-ARIA and would love to use it for everything. Indicating state with aria-expanded is another accessibility standards way of doing things. The only problem is browser/AT support.

Visually Hidden Text

And then of course there’s the good old trusty visually hidden text positioned with CSS off the screen so that the text is physically there, just not visible to sighted folks unless they disable CSS. The great thing about visually hidden text is that it behaves the same in all browsers and AT. It’s always read no matter what and read in the order you place it.

Test Cases (external link) Inline Below

Alt on image

ExpandedHello World

AT Behavior

VO reads link Expanded Hello World

  • VoiceOver OSX 10.8.1 – Alt read then link text.
  • NVDA 2012.2.1 – Alt read then link text.
  • JAWS 13.0.924 – Alt read then link text.
  • VoiceOver iOS 5.1.1 – Only link text read, NO alt.

Null alt on image, title on link

Hello World

AT Behavior

VO reads link Hello World
VO reads You are currently on a link, inside of a HTML content. To click this link, press Control-Option-Space. The help tag is: Expanded

  • VoiceOver OSX 10.8.1 – Link text then title is only read as the help tag after a 7 second delay or pressing control+option+shift+h to read help tag (title) manually. User will not know if a help tag is present unless they wait for the 7 second delay or press the help tag command.
  • NVDA 2012.2.1 – Link text then title (in Firefox). Link text, NO title (in IE).
  • JAWS 13.0.924 – Link text then title (in Firefox). Link text, NO title (in IE).
  • VoiceOver iOS 5.1.1 – Only link text read, NO title.

Null alt on image, aria-expanded on link

Hello World

AT Behavior

VO reads expanded link Hello World

  • VoiceOver OSX 10.8.1 – aria-expanded then link text.
  • NVDA 2012.2.1 – Link text then aria-expanded.
  • JAWS 13.0.924 – Link text, NO aria-expanded.
  • VoiceOver iOS 5.1.1 – Only link text read, NO aria-expanded.

Null alt on image, visually hidden state text

Hello World

AT Behavior

VO reads link Hello World Expanded

There is no difference. Visually hidden text is always read in the order it is placed.

Thoughts on Results

The results are not encouraging. I was going to suggest using either alt on the image or visually hidden text but after testing on VoiceOver iOS 5.1.1 alt on an image is not read. You can say that this is all due to browser and AT bugs because the accessibility coding is correct.

Bulletproof Accessibility

The only bulletproof method is using visually hidden text to indicate state and placing that state text in whatever order you choose it to read. I placed the visually hidden state text after the link text in my test case. The decision comes down to what browsers and AT you support and if you want to work around screen reader/browser bugs to provide a more usable solution or if you chose to follow accessibility standards and wait for the AT/browsers to fix themselves.

Your Thoughts?

Hope this helps! Please let me know if you have any questions or feedback.

I will retest this with iOS 6 GM once I get it installed on my iPhone. I think it handles the title attribute differently with a 2 second delay instead of 7 on OS X.

OnChange Event on a Select Input/Jump Menu Accessibility Problems

On Input Success Criterion 3.2.2

WCAG 2.0’s On Input Success Criterion 3.2.2 states that:

“Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component. (Level A)”

Details here: Understanding Success Criterion 3.2.2 | Understanding WCAG 2.0

Here is my go-to example for this accessibility problem in action: iCITA: onChange Event Example.

Inaccessible Select control shown in Internet Explorer. View Example link to see in action.

Affected Browsers

The only browsers affected by this issue are versions of Internet Explorer (the most popular browsers on the internet when combined) and Chrome. So it’s obviously a problem for Windows users. This problem does not affect mouse users, only keyboard-only/screen reader users. Mac users are also not affected.

Inaccessible Select control shown in Safari on OS X. View Example link to see in action.

Basically the issue is that many times a developer will have a select input menu with different options, often called a jump menu or drop-down menu, that is tied to the onChange JavaScript event. In the iCITA: onChange Event Example there is a list of links to W3C specifications in the select. A keyboard user would enter the select then use the UP/DOWN ARROW keys to make a choice. The problem is that as soon as the DOWN ARROW is pressed the JS onChange event fires and sends the user to the first option causing a change of context. Go try it yourself in IE or Chrome on Windows. Now try it in Firefox or any browser on a Mac. Firefox makes up for the developers accessibility error by preventing the onChange event from firing until the user’s focus leaves the select. Browsers on the Mac actually open the list of options as if you were clicking the select with a mouse. Browsers on Windows do not open the list of options when using keyboard navigation.


There is a workaround for IE and Firefox on Windows to open the select’s options with the keyboard, the command is ALT+UP/DOWN ARROW. So this is great because a keyboard/screen reader user can now open the list of options and navigate between each, read them all, and then finally press ENTER or TAB to activate their selection which then fires the onChange event. Now the only problem is that this does not work on Chrome :(.

Inaccessible Select control shown in Internet Explorer after pressing ALT+DOWN ARROW. View Example link to see in action.

Use onClick on a “Go” Button Instead

The typical solution for this onChange on a select accessibility issue is to not tie the onChange even to the select but rather tie an onClick event to a “Go” button directly after the select. This way any type of user can cycle through all the options in the select then TAB to the “Go” button and activate it to choose their selection. You can see this in action on the Accessible version of the iCITA: onChange Event Example. The problem with this approach is that many designers and developers do not want an extra button or extra step. They prefer the “less is more” approach. G80: Providing a submit button to initiate a change of context | Techniques for WCAG 2.0

Accessible Select control with Go button shown in Chrome on Windows. View Example link to see in action.

Option to Programmatically Associate Change of Context Explanation & Instructions

WCAG does offer an alternative way to meet SC 3.2.2 On Input by placing instructions before the select explaining what will happen. Since most typical web users have no idea about the ALT+DOWN/UP ARROW command this would be a great place to include those instructions. It is also recommend to programmatically associate the instructions with the form control. This could be done using WAI-ARIA’s aria-describedby attribute or for a more bulletproof approach simply placing the instructions in the select’s label. See the details for this approach here: G13: Describing what will happen before a change to a form control that causes a change of context to occur is made | Techniques for WCAG 2.0

Bulletproof Accessible Solution: onClick on a “Go” Button

Providing instructions explaining the change of context and how to activate the select without firing the onChange event right away is good and all BUT this does nothing to help out Chrome on Windows users who cannot use ALT+UP/DOWN ARROW. Therefore, the only truly bulletproof accessible solution to the onChange event on Select inputs is to not use it and instead use the onClick on a “Go” button. Sure you can pass WCAG 2.0 SC 3.2.2 On Change with the instructions approach and you can blame the problem on Chrome but are you really providing a universally accessible solution with that approach? No. So it’s up to you to decide.


I’d love to get some feedback in the comments so fire away! You can find me on Twitter as well @pauljadam.