Captioning Grant Available to NC State Faculty

NC State University has established a Captioning Grant to assist faculty in creating accessible videos.

This grant provides funds for faculty to obtain captions for instructional videos used in their online, blended, and face-to-face courses. In addition to providing content to people with hearing impairments, captions create a learning environment that supports Universal Design for Learning.  

Faculty members may apply for funding to caption videos:

  • when a student with a disability requiring an accommodation for captioning registers in a course that contains video, or
  • when proactively captioning videos to enhance the learning environment for all students.

Faculty using their own videos as a central part of their pedagogy are highly encouraged to apply for the grant.

To apply for the grant, complete the Captioning Grant Application Form. Applications to meet the needs of a student requiring this accommodation will be processed immediately. Those for proactive captioning will be processed on March 31 for summer, June 30 for fall, and Oct. 31 for spring courses.

For more information, see Multimedia Accessibility. You may also send your questions to

Winners of the 3rd Annual NC State Global Accessibility Awareness Day Challenge

(EDIT: Because of a technical problem, the Ocean Observing and Modeling Group site was not originally scanned accurately. The results have now been updated.)

Congratulations to the winners of the 3rd Annual NC State Global Accessibility Awareness Day Challenge! Together we corrected over 125,000 accessibility errors over the past month!

There were two aspects to the contest: which sites could correct the largest percentage of their accessibility errors and which sites could provide a link from their home page to the Accessibility @ NC State site.

Sites correcting the largest percentage of their accessibility errors

Sites linking to the Accessibility @ NC State site

  • BTEC
  • Center for Family and Community Engagement
  • Communication
  • English
  • Foreign Languages and Literatures
  • Horticultural Science
  • Interdisciplinary Studies
  • IT Accessibility
  • Lebanese Studies
  • Ocean Observing and Modeling Group
  • Philanthropy Journal
  • Psychology
  • Recycling
  • Social Work
  • Sociology and Anthropology
  • Student Media
  • Technology Transfer
  • Textiles

2015 Global Accessibility Day Website Accessibility Challenge

NC State University will be hosting our Third Annual Global Accessibility Awareness Day Website Accessibility Challenge. The purpose of the challenge is to

  • promote accessibility throughout the campus
  • improve the accessibility of our websites
  • teach developers and content creators how to build accessibility into their Websites

The contest runs from April 15 through May 20, and the winners will be announced on Global Accessibility Awareness Day, May 21. There are two competitions.

  1. Sites which can correct the largest percentage of their accessibility errors
  2. Sites which can include a link to the Accessibility @ NC State page

Sites which can correct the largest percentage of their accessibility errors

One competition is to see which websites can have the greatest percentage of errors corrected during the contest. Winners will be selected from

  • Large sites (1000 or more pages)
  • Medium sites (100-999 pages)
  • Small sites (less than 100 pages)

Sites which can correct at least 50% or 75% of their errors will also be recognized.

Sites which can include a link to the Accessibility @ NC State page

It is important to allow users to be able to easily find accessibility information about our campus, whether they are looking for accessibility services or are having problems interacting with online content. We have a central place where all campus accessibility information can be found, including contact information – the Accessibility at NC State site.

For the contest, websites which include a link to this site from their home page will be recognized. Including this link is often done by placing it in the footer of your page.

<a href=””>Accessibility</a>

Learning more about Accessibility

Throughout the contest there are a number of opportunities to learn about accessibility and how to make your websites more accessible. Note: All training events are in the Avent Ferry Technology Center, where there is plenty of parking.

Website Accessibility Tune-Ups (Lunch & Learn series)

Bring your lunch and your website for a free website accessibility evaluation from Greg Kraus, the IT Accessibility Coordinator. You will see how he evaluates sites for accessibility and you will go away with actionable items that you can start implementing in your site to improve your accessibility. You can signup in ClassMate with the following links.

Web Accessibility Testing and Techniques

In this workshop you will learn about Web accessibility concepts, how to code for accessibility, and how to use common accessibility testing tools. You do not need to bring your own website for this workshop, but you can work on it if you want to.

Co-Working Day Drop-in Session

Every Friday several people from around campus gather in Avent Ferry Technology Center, Room 106 for a co-working event. A co-working event is just a place where people gather to work on their own stuff or collaborate with people who are in the room to help solve problems they are having. On May 1 and May 8 Greg Kraus will be at the Co-Working Day from 9 a.m. to 4 p.m. to answer any questions you may have about accessibility and work with you on the accessibility of your site. There is no sign up. Just drop on by.

The Incredible Accessible Modal Window, Version 3

I’ve made a few minor updates to the Incredible Accessible Modal Window.

  • removed the role=”document” from the contents of the window. This was originally inserted to deal with the way NVDA interacted with role=”dialog”, but that issue has since been resolved in NVDA.
  • made the close button an actual button instead of a link. I should have done this a long time ago and don’t know why I didn’t do it sooner.

View the Incredible Accessible Modal Window, version 3.

Previous versions of the Incredible Accessible Modal Window

Note: This is edited from the original post to reflect an error in the first bullet point where it originally said role=”dialog” instead of role=”document”.


Winners of the 2014 NC State Global Accessibility Awareness Day Website Challenge

Congratulations to all of the developers who participated in the 2014 NC State Global Accessibility Awareness Day Website Challenge. Together we corrected 905,082 accessibility errors!

For each of the size categories, the Web sites that corrected the largest percentage of their errors are

  • Large Sites (1000+ pages)
    • NCSU Libraries (84% of errors corrected)
  • Medium Sites (100-999 pages)
    • African American Cultural Center (66% of errors corrected)
  • Small Sites (1-99 pages)
    • Internal Audit (25% of errors corrected)

For the ARIA Landmark portion of the challenge we had 21 sites add the main landmark to at least 80% of their pages and 23 sites add the navigation landmark to at least 80% of their pages.

Just a  note, there are actually a lot more sites on campus using those two landmarks. Because of the way the scan was run, only those sites which requested a rescan during the contest were counted in these totals.

2014 NC State Global Accessibility Awareness Day Website Challenge

The University IT Accessibility Office is once again sponsoring the NC State Global Accessibility Awareness Day Website Challenge to encourage campus website owners and designers to make accessibility improvements to their websites. Global Accessibility Awareness Day is held annually “to get people talking, thinking and learning about digital accessibility and users with different disabilities.”

The contest, which runs April 15 to May 14, includes two categories:

  • Sites that improve their overall accessibility by the greatest percentage.
  • Sites that have the ARIA roles “main” and “navigation” added to at least 80 percent of their pages.

You can view the current leader boards and see how you stack up against the competition. The winners will be announced on Global Accessibility Awareness Day, which is May 15. Sites will be considered in three size categories for determining the largest percentage of accessibility errors corrected.

  • 1000+ Pages
  • 100-999 Pages
  • 1-99 Pages

You can learn more about adding ARIA landmarks to Web pages. Also, you can come to a number of workshops and training sessions over the next month to learn how to make your Websites more accessible.

Incredible Accessible Modal Window, Version 2

UPDATE: Read about version 3 of this demonstration.

Just take me to the demo of the Incredible Accessible Modal Window, Version 2.

Rich Caloggero at MIT and I were talking recently about screen reader support in the original Incredible Accessible Modal Window and he pointed out to me that different screen readers handle virtual cursor support differently in the modal window. This sent me further down the rabbit hole of screen reader support with ARIA and what exactly is going on.

The Situation

I hesitate to call this the “problem” because I’m not sure what the real problem is yet. I’m sure it is some combination of differing interpretations of specifications, technological limitations of different screen readers, design decisions, the needs of the user, and bugs. The situation is that all screen readers, except for NVDA, can use their virtual cursor to navigate a role=”dialog”.

The root of the situation is that a role=”dialog” should be treated as an application window. This fundamentally changes the way a screen reader user interacts with an object because the default way the user is to now interact with the application window is by using the application’s defined navigation methods. In other words, the screen reader user is not supposed to use their virtual cursor.

It is clear from the spec that when a screen reader encounters an object with an application-type role, it should stop capturing keyboard events and let them pass to the application. This in essence turns off the virtual cursor for JAWS and NVDA. What is not clear is if it is permissible for the user to optionally re-enable their virtual cursor within an application. JAWS says yes and NVDA says no. (Just a note, JAWS actually requires the user to manually enable application mode instead of doing it for them automatically.)

This has real world implications. Typically for a role=”dialog” the user would use their Tab key to navigate between focusable elements and read the page that way. But what if there is text within the modal dialog that is not associated with a focusable element in the modal dialog?

The spec says that “if coded in an accessible manner, all text will be semantically associated with focusable elements.” I think this is easily achievable in many situations, however, I question if it is practical in all situations. In my experience a lot of content is being crammed into some modal dialogs, sometimes more content than can always be neatly associated with focusable elements. In theory, with enough tabindex=”0” and aria-labelledby attributes you could associate everything with a focusable element, but I wonder if this would get too unwieldy in some situations.

There is always the question of if developers should be cramming so much information into modal dialogs, but that’s another discussion for another day. I’m simply trying to deal with the fact that people are putting so much content in there.

A further real world implication of the ability or inability to use the virtual cursor is if you allow users to use their virtual cursor in some situations in an application region, are there situations where that could end up hurting the user? For example, it’s not hard for me to imagine a modal dialog where it would be useful to allow the user the ability to navigate with their virtual cursor, however, if a screen reader user is interacting with Google Docs, which is in essence one large role=”application”, the results can be disastrous. Are there certain application contexts where we would want the user to be able to enable their virtual cursor and other contexts where we would want to prevent it? That just made things a lot more complicated.

Just to complicate things more, VoiceOver and ChromeVox don’t really have a concept, to my knowledge, of turning a virtual cursor on and off. That means they can browse the contents of the role=”dialog” any way they want, and there is not much I as a developer can do about it.

A Partial Solution?

One of the things Rich and I learned in this adventure is if you include a role=”document” inside of the role=”dialog”, then NVDA allows you to use the virtual cursor. This now gives all screen reader users the ability to fully navigate all of the contents.

Is this a good thing? Based on the reality of how people are actually implementing modal dialogs, I think it is. Some modal dialogs are in essence becoming miniature versions of Web pages, not just simple forms or messages. Given the alternative of having to programmatically shoehorn every piece of text into a relationship with a focusable element, I think this is a good option for some pages.

I still think that people should revisit the overall usability of their application which might require such complex modal dialogs in the first place. There are probably better ways to design the user interactions.

So is NVDA wrong in their implementation of not allowing virtual browsing in an application? I don’t think so. That is the intention behind the application region. Is JAWS wrong for allowing the use of the virtual cursor in an application? Probably not, because it is always good to give screen reader users the option of trying to save themselves from bad coding and using the virtual cursor might be the only way they can do that. However, my guess is that using the virtual cursor in something designed to be an application will usually lead to more confusion than assistance.

VoiceOver Improvements

One additional improvement – in the original version of the Incredible Accessible Modal Window there was a shim in place for VoiceOver users so that the aria-labelledby attribute would be automatically announced. VoiceOver in OS X 10.9 fixes this problem so the shim is not needed any more.

2013 NC State World Usability Day Website Challenge Results

Congratulations to all of the NC State Website owners who participated in NC State’s 2013 World Usability Day Website Challenge. NC State users can view the detailed results of the challenge. Website owners competed in two areas.

  1. Which sites, in their respective size categories, could correct the largest percentage of their accessibility errors in the month leading up to World Usability Day.
  2. Which sites could include a skip to main content link on at least 80% of their pages.

Accessibility Errors Corrected

Together we corrected a total of 416,196 accessibility errors for this challenge. Since the Accessibility Scan started in March of 2013, we have collectively corrected 1,188,908 accessibility errors.

Skip to Main Content Links

During this challenge we added 2,661 new skip to main content links across our pages, with 128 of our sites now having skip to main content links on at least 80% of their pages.

Congratulations again to all of the NC State Website owners!

NC State Web Accessibility Challenge on World Usability Day

NC State University’s Office of IT Accessibility is sponsoring a Web Site Accessibility Challenge in conjunction with World Usability Day. World Usability Day brings people together “to ensure that the services and products important to life are easier to access and simpler to use.” In order to encourage Web site owners to help make our university Web pages more accessible, there are two challenges.

  1. To address general usability, which sites can correct the largest percentage of their accessibility errors.
  2. To address users who cannot use a mouse, which sites can add a specific accessibility feature to at least 80% of their Web pages – the ability to allow users to skip to the main content of a page using only a keyboard.

To learn more about your Web site’s accessibility and to see tutorials on how to improve its accessibility, view your Web Site Accessibility Scan.

To learn more about adding skip to main content links to a page, view the Skip To Main Content Link Tutorial in the Web Accessibility Handbook.

The contest winners will be determined by the last rescan submitted by 11:59PM on November 13 and the winners will be announced on November 14 on World Usability Day.