Welcome to WordPress. This is your first post. Edit or delete it, then start writing!
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:
- Bug #
- Steps to Reproduce
- Expected Results
- Actual Results
- User Agent
- Assistive Technology
- URL to Bug Report
- Bug Report ID#
- Bug Reported By
- 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 🙂
|Bug Tracker||URL||Details/Bug Reporting Guidelines||Bug Type|
|Apple Bug Reporter||http://bugreport.apple.com||Screen Reader
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
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|
|NVDA Issues||http://community.nvda-project.org/wiki/Issues||Screen Reader|
|GNOME (Orca) Bugzilla||https://bugzilla.gnome.org/enter_bug.cgi?product=orca||Screen Reader|
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 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
— a11y bugs project (@a11ybugs) July 19, 2013
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”.
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
- WebAIM’s Web Accessibility Practitioner and User Surveys: Data and Trends
- Let Mobile Apps Speak for Themselves: Accessible Mobile Apps Through Voice
9:00 AM PST
- CSS, Accessibility, and You
- The Access Board Public Hearing
- Firefox OS Accessibility
- What’s New for Accessibility in Internet Explorer
- Yahoo Demonstrates Our Accessible iPhone and iPad Mobile Apps
10:00 AM PST
- Pattern Library Hack-A-Thon; Part 1
- The Access Board Public Hearing (Cont.)
- iWork Accessibility in Mac OSX
- Videos and Accessibility
11:00 AM PST
- Pattern Library Hack-A-Thon; Part 2
- Mobile and Accessibility
- Yahoo Demonstrates Our Accessible Android Mobile Apps
- GOV.UK: The UK’s New Digital Public Services And What They Can Teach You
1:20 PM PST
2:20 PM PST
- Moving the Accessibility Needle-DOJ & the Access Board
- Accessibility in an Agile World
- Adobe Town Hall
3:20 PM PST
- Screen Reader Web Accessibility Face-Off II — No Holds Barred
- Accessible Design: Which “Everyone” Do You Mean?
4:20 PM PST
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
30th Anniversary Celebration & Reception, http://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 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
- Accessibility & UX: A Pattern Library Love Story
- The Accessible Android App Experience
- Bootstrap.js Dynamic Web Accessibility and “SkipTo” Page Navigation
- What a Web Developer Needs to Thrive in the Accessibility Ecosystem
10:00 AM PST
- Diving into the Deep End: A Discussion on SVG, Angular, and Accessibility
- Digital Accessibility: 2015 Annual Legal Update
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
- Web Components: Background, Opportunities and Challenges
- Do We Need To Change the Web Accessibility Game Plan (Redux)? (Glenda works at Deque!)
- Beyond Screen Readers: Voice-based, Mobile Apps that Put Blind Users First
- Future Plans for W3C WAI-ARIA Authoring Practices Guide
- Fan Captions and Subtitles at YouTube
2:20 PM PST
- Creating Layered Learning Environments with AR and iBeacons
- Increasing Accessibility Through Collaboration on Open Source Projects
- Creating Section 508 Compliant Native iOS Apps
- Parting the Red Sea of inaccessible corporate web sites: escape the broken (Keith works at Deque!)
3:20 PM PST
- Techniques Showdown: 4 Hot Web Accessibility Issues from 1999, Still Issues
- The Ghosts of Accessibility Laws: Past, Present, and Yet to Come
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 🙂
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 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.
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
- https://twitter.com/search?q=%23CSUN15, Don’t forget to search twitter #CSUN15 and #CSUN2015 is also used.
Hey #CSUN15 folks please come to #DequeParty2015 Wed after 1st day of sessions for food, drinks, music, karaoke #a11y http://deque.com/csun2015
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.
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.
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 🙂
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
Your form could not be submitted because of 3 validation errors.
Results of role=alert on Static Text
Live Before & After Demo:
VoiceOver OS X “Help Text” or “Hints”:
After on Android in Firefox with TalkBack:
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! 🙂
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.
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.
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.
Jim Thatcher’s Favlets showing errors on the labels and inputs.
Since there is no connected label VoiceOver reads “edit text Placeholder text”.
Yelp’s Inaccessible Form Labels Code
<input type="text" placeholder="tacos, cheap dinner, Max's">
<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
<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
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 🙂
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.
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
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
- 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
- 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
- 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
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.
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.
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.
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)”
Here is my go-to example for this accessibility problem in action: iCITA: onChange Event Example.
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.
ALT+UP/DOWN ARROW Workaround
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 :(.
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
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.