Category Archives: Screen Reader

Simple Accessibility Updates to Improve New York Times New Redesign – Part 2

Posted on by

For those following along, this is Part 2 of my series on how the New York Times can make simple updates to improve their website’s accessibility. “Part 1 – Simple Accessibility Updates to Improve New York Times New Redesign” is available for those who missed reading it.

Reminder: I’ve written these posts to help to the New York Times, along with anyone with large websites, or those who are designers or developers, etc., to show that simple incremental changes can improve their website in the long run.

In this post, I will cover the following accessibility issues with the New York Times home page:

  • Missing skip navigation
  • Difficultly seeing visual cues for those only using the keyboard
  • Poor color contrast
  • Not able to use video player by keyboard only
  • No captioned videos for individuals that are deaf or hard-of-hearing

Adding Skip Navigation

Skip navigation allows people that use a keyboard or assistive technologies like screens reader JAWS, NVDA, VoiceOver, etc.) to bypass large sets of links and focus on the content. Unfortunately, the New York Times pages are missing skip navigation, which means that screen reader users must listen to all of the preceding content before getting to the main articles.

Adding skip navigation to your pages is fairly easy as shown in this article on my blog called “Are You Using Skip Navigation?”.

You can choose between a few different techniques to hide your skip navigation depending on what your design team or marketing department want. Here are a few articles about skip navigation:

Note: These websites have additional accessibility articles you might want to read when you have the time.

An example of skip navigation can be found on my main website (press TAB to see the “Skip to Main Content” link at the top of the page). I haven’t yet updated my blog’s WordPress theme to include skip navigation.

Visible 'Skip to Main Content' link on jfciii.com website

Thinking About Color Deficiency (Colorblindness)

Approximately 8% of the population (mostly male) has one of the three main types of colorblindness (deuteranopia, protanopia, and tritanopia). This, along with small text, might make it difficult to read parts of the New York Times homepage.

The following examples demonstrate what people with normal vision see as compared to the three main types of colorblindness:

The opinion page section with now colorblindness mask added

Normal vision

Deuteranope colorblindness mask added to the opinion page section

Deuteranope (a form of red/green color deficit)

Protanope colorblindness mask added to the opinion page section

Protanope (another form of red/green color deficit)

Tritanope colorblindness mask added to the opinion page section

Tritanope (a blue/yellow deficit- very rare)

To help people who are colorblind, the New York Times needs to verify the color contrast ratios.

Analyzing Color Contrast

For those who have low vision, poor eyesight, or colorblindness, some of the text on the New York Times home page could be difficult to read. An example would be the bylines to their articles.

New York Times feature article bylines

Bylines from New York Times feature articles on home page

If you were to use one of the many check color contrast tools, such as Jonathan Snook’s “Colour Contrast Checker” you input the foreground (font/text) color and the background color to see if it passes WCAG 2.0 standards:

  • Level AA: contrast ratio of 4.5:1 for normal text and 3:1 for large text
  • Level AAA: contrast ratio of 7:1 for normal text and 4.5:1 for large text

You can be get the hexadecimal numbers from Photoshop (designers), or by right clicking the text and having the Firefox plug-in FireBug (developers). In this case the CSS is:

.NYT5Style .byline { color: #808080; font-size: 10px; line-height: 12px; margin: 4px 0 2px; }

The screenshot shows the Colour Contrast Checker after I added the CSS from one of the home page bylines. As you can see, the foreground color #808080 is a light gray, which has inadequate color contrast on a white background with a ratio of 3.95.

New York Times poor byline color contrast show on Jonathan Snooks colour contrast tool
Another reason it might be difficult for others to read the byline is because the font size is only ten pixels (10px). I recommend that the font size be no smaller than 12 to 14 pixels (12px to 14px) depending on font choice. The font Arial at 12 pixels (12px) is smaller than Helvetica at 12 pixels (12px).

Some of the more popular color contrast checkers/resources are:

Providing Visual Cues for Keyboard-only Users

It is difficult to see where you are (that is, which links are active) when tabbing through the home page. One way the New York Times can fix this is by adding “:active” (IE browsers) and “:focus” (for all other browsers) in the CSS to the elements that include “:hover.” Then, when you tab, the links are indicated (in this example, with an underline).

Here are the current and updated examples of the CSS:

Current CSS

a:hover { text-decoration: underline }

Updated CSS

a:hover, a:focus, a:active { text-decoration: underline }

Making the Video Player Keyboard Accessible

Keyboard-only users cannot play, pause, enlarge the video to fill the entire screen, or change the volume.

A friend who works in the accessibility field asked if I knew of any way to make a YouTube player keyboard accessible for a .gov website he and his team were working on. I told him how Derek Featherstone and his team had used YouTube’s API to create their own links to play, pause, etc. the video by using JavaScript and CSS to place the links over the inaccessible ones. Due to time constraints, my friend and his teammates added an additional set of controls below the video, which did the trick of making the video player accessible.

Captioning Videos

I looked at several videos on the home page, and none of them had captioning. Lack of captions can make following, along with the video difficult for those that are deaf or hard-of-hearing .

Solve this problem by getting the videos captioned. Many services are available that will caption your videos for a price. The quality of the captioning somewhat depends on how much money you have to spend.

No captions for this video and no ability to turn them on if they were available

No captions available

Another solution is to take a transcript, if available and use captioning software that will split the text/captions at the correct places.

Conclusion

So this concludes Part 2 of my series on “Simple Accessibility Updates to Improve the New York Times New Redesign”. The next blog post will be about the accessibility issues found on the article pages, which I’m guessing will have similar issues as the home page does, and finally how to use all the tools I used.

I hope this post helps you find easy ways to check your websites quickly for accessibility issues, along with pointing out a few free tools you can use.

If you have other tools or software that you use to check website accessibility, please add them in the comments, because not all tools will find all the issues.

References

Screen Readers

Skip Navigation Articles

You can find more great accessibility articles on both of these websites.

Color Contrast Tools

Edited by: Char James-Tanny of JTF Associates, Inc. – @CharJTF

How to Improve Your Search Usability

Posted on by

Doing searches on websites is a pain when you are using assistive technology. There are ways to improve how you get to the results.

Why not add an HREF anchor like #maincontent, which we used for the “Skip Navigation” article to your “Search Results URL” so those using screen readers, other assistive technologies, keyboards only, or other non desktop web browsers to skip right to the results section of the page skipping all the header, primary navigation links, and secondary navigation, etc.

You also need to make sure you have a LABEL connected to your search box for screen reader and other assistive technology users to know what they are looking at. Below is some sample code you can use as a starting point, along with some CSS to hide the search LABEL visually off screen if your design calls for that kind of things.

Search Form Code

<div class=”SEARCH“>
<form name=”Skills_Search” action=”searchResults.html#MAINCONTENT“>
<label for=”search2“>Search</label>
<input type=”text” name=”search2″ id=”search2” />
<input type=”submit” value=”Search” />
</form>
</div>

Results of Search Code



To hide the word “Search“ just add to the hide class used for the skip navigation blog post this can be done easily by adding “.search label” to the CSS.

Here’s a live example of the search box and search results example page.

Hope this little change to your website was helpful to you and it will make accessing the internet for those using assistive technologies better.

If you have any questions or ways to improve this, please leave a comment or get in touch with me.

Why I’m Building Hold An Event

Posted on by

I created Hold An Event because all the other event registration web applications are not accessible to those using assistive technologies, like screen readers (JAWS, NVDA, Window Eyes, etc.), along with voice recognition software (Dragon Naturally Speaking). They are also difficult to use even on smartphones let alone an lesser phones. I found this out while running my first Accessibility Camp DC back in October of 2009 and then with our follow-up monthly event, Accessibility DC. People would show up without registering because they deemed the service I had chosen not to be accessible, even though these people would be considered by most to be power assistive technology users.

After the first Accessibility Camp DC and a few monthly meetings, I started looking into event registration systems and everything I found was inaccessible in one form or other. I mostly looked at all the larger ones is all. So over the last two and a half plus years, when I have had five minutes here or a half hour there, at coffee shops, on the train, or wherever, I put notes into my iPhone about creating a web-based event registration application. At first, I used the iPhone’s built-in notes application, until a few people suggested I use Simple Note. This was because it had an iPhone application, along with a web application. By gathering all the different pieces of information you would need to create and run events over time, I had the time to really think about the roles/personas needed for an event.

The type of people I came up with could be people putting on the event, the attendees, paid attendees if that applies, sponsors, speakers, and even event staff. These roles work if you are holding a simple birthday party, the monthly book club, a tech event, or even a large conference. So we are talking a great amount of information, and I really had to think this through.

At times, I was like this is way too much work for just one person or I had other things to do and would do nothing about it for weeks or even months. No matter how hard I tried, the problem never seemed to go away and kept coming back to me. So after reading a lot of books, articles, etc. about start-ups, web applications, usability, and the like, as most would say I just needed to start and see where it would go.

When I Started

So over the summer of 2011, I finally started building the prototype to make sure I had the correct process, flow, and usability of the web application down before really starting the difficult work of making this a true working application. I even started with the mind-set of Mobile First (great book), which some are great ideas from Luke W. and others. My guess was that if I started coding the web application using web standards and accessibility in mind from the start, and if a person could do everything they needed to on their phone, then it should work wonderfully in a browser or on a tablet.

I started out simple and built a few of the needed input forms, which got me playing with responsive design and media queries. I made a concerted effort to get those few main screens right before building out a ton of pages. Once I got most of that complete, I moved on to the next set of forms.

My goal was to have the ability to make Hold An Event’s web application to seem like it was processing real information such as a search for events, to registering for an event, etc. This was done by passing parameters in the URL to tell each page what static content to place on the page. This idea seems to be working fairly well, since when showing friends lately what Hold An Event looked and acted like, they asked what kind of database, etc. I’m using. I would then explained what I had done to make it a look like a fully-functional application.

By the middle of October 2001, I had a bunch of pages that worked well enough to start showing people at that month’s Accessibility DC event and then more people at my annual Accessibility Camp DC event. Once those events were over, I didn’t do any more coding until New Year’s Eve 2011, sitting at my parents kitchen table coding from like 11 PM to 1:30 AM, because everyone else in the house more or less had gone to bed by 10:30 PM. Since then, I have been doing something to improve the Hold An Event web application just about every night and on the weekends too. Sometimes it was a little tweak here or there; other times it’s been to add a new page.

At one point, I added a few different smaller non geek/tech events to be able to show people different types of events types and how the process worked. I also had to add in some code to display the different navigation paths people used, depending on what type of user they were. For example, is the person running the event or attending the event, which are the two types I’m worrying about now.

How You Can Help

The next step is to let people play with Hold An Event themselves instead of me demoing it on my iPhone, which means making it look and act better on a tablet or in a computer browser. Currently it’s not the prettiest thing in a web browser, but it will do as a prototype.

Other big tickets items I’m going to have to think about are the security of peoples’ information like name and e-mail address to start, along with taking money, once I get to that point, which is far off in the future. I’m only working on this a few hours some nights after work and then 6 hours max on the weekends, for a total of 10 to 15 hours a week.

So here’s to making more progress over the next few months.

Where to find the Hold An Event Prototype

For those wanting to look at the current prototype, start by using the “tab” key on the Hold An Event’s home page, doing so will let you find the link to the demo/prototype web application. Remember this “prototype will not save” anything you place in it at all. So please don’t try and create an event to invite people to it and think it will work because it won’t. Once you’re there, use the search box to find events in “DC”, which will currently give you a list of nine events to view.

If you want to sign in to see the process of creating and viewing current events you’re running, your past events, or ones you’re attending, all you need to do is make sure you place at least one character in the user name and password fields. It doesn’t matter what they are, just as long as there is something there.

Feedback Welcome

P.S. Have fun and please send me feedback about what needs to be done, improved, etc. I’m a big guy and can take the the bad with the good. I’m mostly looking for ways to improve things.

I’m Not Dead Yet (In a British Accent)

Posted on by

I know a few of you have asked if I had written anything on my blog in a while and I have had to say no I have not. After reading @Nacin‘s blog post yesterday about it being months, since his last post I figured I might as well work on one myself.

After checking I found the last time I blogged was on September 19, 2010, and it was about “Accessibility Camp DC – October 9, 2010”, which was a great time in case anyone wanted to know. I had wanted to write a blog post a month or so ago, but it probably would have been about Accessibility Camp DC 2011 and it would have looked like I only post when I’m pushing one of my own events, which I actually need to do more of so we get more people attending. By attending the monthly event was so people can learn from each other as well as make new friends.

For those wondering how long it’s been, since I blogged last it has been 443 days or 1 year, 2 months, and 17 days.

To give you a better idea of how long it’s been, we have had our third Accessibility Camp DC, started our third year of monthly Accessibility DC meetings, and I even started working on my web based event registration prototype “Hold An Event”.

Information about Hold An Event

“Hold An Event” is going to be an accessible web based event registration application. The most important part of the application is that it will be accessible as possible when completed, since the event registration system we are currently using now is not accessible. Need to make sure this web application is usable by screen reader users, those, using voice recognition software, voice over (iPhone and iPad), and any other assistive technology.

I’m starting by building the mobile part first. I figured if you can register for an event or even create an event on your cell phone, then it should be even easier to do those tasks in a browser or on a tablet. I have spent most of the last two plus years gathering information about the different people that are likely to use the system and what types of functions they will need from the start and those that can wait until later.

More to come about “Hold An Event”, once the prototype is a bit further along, so I can get feedback on it from others.

Events Attended

During 2011 I attended the following events/conferences:

That’s enough for now.

P.S. For those that don’t know the blog post title was a play on the Monty Python skit “Not Dead Yet”.

Notes for Running an Accessibility Camp

Posted on by

The following is a gathering of my thought for putting on an Accessibility Camp (BarCamp style event) here in Washington, DC last fall. Some of the items listed here were due to the fact that we had individuals that were either blind or visually impaired, deaf or hard of hearing, or had some other disability.

Accessible copies of these notes in both Microsoft WORD and PDF formats will be at bottom of this blog post. (<b>** UPDATED – 2010/09/12 **</b>)

The most important part after getting a few good helpers is to get yourself a location, location, location that is accessible to all first before worrying about a date. One of the hardest parts of putting on Accessibility Camp DC was finding a free location near the bus and the metro (subway).

I spent from about the beginning of May until the middle of August looking for a place to have the event. Then it was a few weeks to get all the approvals from the Martin Luther King Jr. library to have the event there. The library normally doesn’t allow people to have more than one room let alone a few for an entire day, it’s normally just a few hours. Luckily I had had someone that worked there and in the Adaptive Technology Center where part of the event took place.

They have a great deal of assistive technology for all the patrons that use the equipment on a daily basis. By having it a the library we had a whole other level of complexity, since they were sending notes out to all the people that attend their other monthly events. By doing so we needed to have CART (Communication Access Real-Time Translation) which is a device for people that are hard of hearing, Sign Language Interpreters (SLI), and the like.

The next thing to make sure you have at your location is some of the following that have to do with the facilities.

Facility requirements

  • screens and projectors
  • wifi
  • Ethernet connections for speakers at least
  • mirco-phones for speakers and ones to pass for questions (optional)
  • CART – “Communication Access Real-Time Translation”
  • Sign Language Interpreters (SLI)

Next thing to worry about is enough sponsors for the event. The more money you have the more people that can attend. We allowed a maximum donation of $250 so large companies could have try and have a say over the event. We also had a minimum amount of $50, so you did not lose a good chunk of your money to Paypal fees etc. We have found that some of the people/companies that gave the least expected the most from us. One even complained that they were not on the website list only a few hours after giving us the money. They forget that some of us have day jobs and can’t just get on the server from the office to update things.

If you have an over abundance of money you could get t-shirts with the events logo, date, location on front and list of sponsors on the back in alphabetical order so there are no issues. Also please don’t forget to put the people’s whose venue you are using on this list like we forgot last year for BarCamp DC.

You should create yourself a twitter account, purchase a domain, and figure out a short hashtag. We ended up using #AccessDC or was it #AccessCampDC, since #ACDC reminded meet to much of the band and would make it harder to search for on twitter search.

The next big item to start thinking about is food. We provided a small breakfast type stuff that we could use later in the day for snacks as well.

Breakfast

  • bagels
  • coffee
  • juice
  • OJ
  • doughnuts
  • breakfast bars

Lunch

  • pizza or sandwiches
  • chips
  • cookies
  • fruit (banana’s, apples, grapes, etc.)

Snacks

  • candy (chocolate seems to work best)
  • leftover breakfast bars
  • chips and the like
  • leftover fruit

Drinks

  • juice
  • coffee
  • soda
  • bottled water
  • coffee creamer or half and half

Miscellaneous Items

  • paper plates
  • napkins
  • silverware
  • cups
  • butter
  • jam
  • cream cheese

Create a nice accessible website, which we can link to from www.AccessibilityCamp.org once up I get it back up. We just used www.AccessibilityCampDC.org and placed a lot of information there. We had date, location, registration link, sponsors list on the home page at the bottom with links to their websites, a sponsors page, resources page for slides, links, etc. that came out of event.

Don’t forget to create an empty Google Excel type document the night before with talk times, room name or number, if it has a projector, and the like. This saves time and also allows you to create a www.bit.ly URL that will give us statistics on when and where people click on the link.

While still at the event we asked people if they would like to attend a monthly accessibility meeting to keep what you started going. People really wanted to keep it going so we just had our third monthly meeting and have speakers booked for the next two or three months already.

Registration

You will need to find a place/website to take registration for attendees and money from sponsors. We used www.eventbrite.com, which is not completely accessible (issues with e-mails for those using screen readers and other assistive technology), but allowed sponsors to pay with credit cards and put money in your or someone’s Paypal account. We have found it easier to get sponsors money once you have a firm date and location.

Do to the issues with attendee registration, sponsor money, and just admin for the worker’s, I have started wire-framing and gathering information to make my own conference registration web application. Hope to have it ready for our next big event sometime in the fall.

We started our registration with tickets for only a third or a quarter of the total number of people our location could hold. We notified people by twitter and word of month of the date event tickets would go on sale, this way people don’t grab tickets a month or two in advance and never show. We started with having 50 tickets available and said we were pacing them out over a few weeks up until 150 tickets as long as we got enough money. Plus, we wanted to make sure we had enough money to feed everyone. The following weeks we would let like 25 or 50 more tickets go at a time.

Make sure to ask the attendees at registration if people will need assistance (for individuals that are blind, need CART, SLI, Braille version of schedule, etc). We also asked for t-shirt sizes just in case we got them, this way we would not have all the wrong sizes and it would make ordering easier. We also stated that we might have them if enough money was not collected in time or at all, which is what happened with the slow economy.

Make sure the week before to send a note reminding people of the event etc. plus listing the sponsors. We also asked them to give up their ticket if they knew they were not going to be able to make it to the event.

We had 125 people register and the last week about 10 – 15 canceled, since ours was held over Columbus Day weekend. Day of the event we had a few volunteers to the MLK library keep track of who came and signed in. We ended up with 80+ people that we could verify. This is a huge percentage of people that actually showed, since at our three BarCamp DC events we get from 50% – 60% of the people registered to show up.

Amounts of Food and Drink

I also have a whole bunch of information about amounts of food to order from doing Accessibility Camp DC and three BarCamp DC events now if you would like as well.

It is really cool to see if you can donate the leftover food, drinks, etc. from the event to a shelter or somewhere that could use it. First year we did that we found that some places would not take leftover pizza even if it wasn’t missing any slice from the box. This year we left all the snack and drinks at the library for other events that they have.

Other Important Items

A few other things we did was spend twenty minutes having everyone there introduce themselves with name, job, three words that describe themselves. Also have them tell everyone the name of the talk they want to give and a short description, this way you can build the schedule while people get to know who is there and you can make sure all the design talks or whatever are not at the same time.

You might want to plan some sort of JAWS screen reader demo during lunch so people that never have seen one get a chance to do so. A lot of people in DC that watched one for the first time were just amazed at how much goes into getting around the internet with a screen reader.

Another thing would be to plan the talks to be about 45 minutes with questions so people have time to hang out and get to the next talk easily. You also might have people available to help individuals that need help (visual issue or the like) get from one room to the next, since they are in a strange place.

I know BarCamp’s are supposed to be an un-conference with nothing planned, but not knowing how many people were going to come to talk we made sure we had at least enough talks to fill one room for the entire day. We ended up with about 13 talks for the day in three different locations.

Finally you might need a location for after party, which should also be accessible. This allows you to use up any leftover money from sponsors, since BarCamp type events are not meant to make money, but share knowledge and make new friends.

My Cell Number

Hopefully this is what you were looking for and I did not miss anything. If you have any questions you can give me a call at 703-587-2458, anytime normally between 8 AM and 11 PM eastern standard time.

A few other groups have showed interest in me sending this to them so could you give me your opinion of anything I might have missed or over stated.

Microsoft WORD and PDF Version

Here are the Microsoft WORD and PDF versions of how to run an Accessibility Camp notes.