Writing to be read… by a screen reader

Screen readers? What?

If you’ve heard anything about web accessibility, you’ve probably heard of screen readers – devices that allow blind or vision-disabled people to access websites by listening to a speech synthesizer or, in some cases, via a braille display. There are a number of different screen readers; this recent review of three popular screen readers is interesting – the comments in particular illustrate that “accessibility” is different for different users with different needs, an important thing to keep in mind.

If you’ve never seen a screen reader in use, by the way, there are some good videos out there. I like the one embedded below; using JAWS – one of the more popular screen readers – the narrator goes through the BBC website and shows you how it works. Pay particular attention to how the screen reader handles links and headings, and you’ll understand why we always say that you should use heading tags when your page has sections rather than just making the section title bold and why we always say that your links should be semantically meaningful rather than just saying “click here.”

WebAIM, a great source for web accessibility information in general, has an extensive overview of how screen readers work and how to design for them. One of the most important points they make is that, while sighted users tend to quickly scan the entire screen and focus on what stands out as looking important to them, screen readers present content in a linear fashion. (Another “what it’s like to use a screen reader” video I found mentions that in another context: if a student receives a lengthy email from an instructor, they  have to go through the entire email and remember what they have to do or respond to once they’re finished, or even literally take notes on the email as they listen – they can’t just scan the email or easily go back and forth between the email and the response they are composing.)

But I’m not a web designer. Should I care?

What does this mean for those of us who don’t design entire websites, but who do write and publish content on the web? Well, for one thing, a giant block of text is going to be a huge pain for someone using a screen reader. Since they can’t quickly scan to figure out what the most important points are, they are going to have to sit and listen to the entire block of text. It would be much easier for these users to break up your content into smaller portions, using heading tags to separate them.

You’re not breaking it up at random, of course – more than just controlling font size and weight (for sighted readers), heading tags describe how your content is structured. Think of how an outline works – you have section I, and below that sub-sections A, B, C – then section II, and so on. Headings work the same way. H1 is generally your title, then H2, then on down as far as H4 if your content is that complex – then back to another H2, and so on. Or, think about a book with sections and chapters – or even feature story in the newspaper, which may have a headline and multiple sections, each with its own smaller title or headline.

This post, for example, uses heading tags instead of just rambling on and on nonstop. Ta-da!

Great news: Structuring your content using these semantically meaningful, well-organized heading tags also makes it easier for sighted users to scan your page and quickly spot the content they are looking for.

Accessibility benefits everyone.

This is a recurring theme that you find once you start learning about accessibility: many of the measures you take to make your website usable for disabled users are actually usability improvements for most of your users. This is true of accessibility features in the offline world, too – the button that lets someone using a wheelchair open a door is also helpful for a non-disabled (I love the term “temporarily able-bodied“) person whose arms are full of packages.

"Accessible" painted on pavement
flickr: Jonathan Moore CC BY-NC 2.0

The thoughtful folks over at GOV.UK (run by the Government Digital Service, the group responsible for designing digital services for the UK government) recently published a great post, “How to create content that works well with screen readers.” They don’t offer a bulleted to-do list, but rather discuss how screen readers work and some of the potential implications for writers of web content. For example, it’s useful to think about how screen readers interpret acronyms. It shouldn’t come as any surprise that this article concludes that writing content that works well for everyone will benefit screen reader users. Proofreading your content to make sure words are spelled correctly and using consistent standards for how you deploy acronyms and abbreviations, for example, will benefit everyone.

Of course, blind and vision-disabled users aren’t the only people with disabilities who use the web. People with color-blindness, deaf or hard-of-hearing people, people with limited fine motor control or who have difficulty using a mouse, and people with cognitive or memory disabilities can all have a better experience on the web if content is thoughtfully designed.

Captioning your videos will make them usable not only by deaf users but also by those who may want to watch your video in a public place but don’t have a pair of headphones handy. Plain language helps dyslexic users, those for whom English is a second language, and people who are in a hurry. And breaking up those intimidatingly huge blocks of text into more manageable chunks helps pretty much everybody. Making your web content accessible isn’t about providing “special” access to a few users – it’s about providing good access to ALL users, including those with disabilities, while remembering that for some users it means the difference between being able to access your content and being told “no, this content is not for you.” (Besides being a violation of the ADA, that’s just plain rude.)

Want to learn more?

If you find yourself intrigued by these issues, WebAIM’s Introduction to Web Accessibility is a great place to start. For IU-specific accessibility information and some great resources to help you create accessible content, visit Accessibility at IU. The UITS Assistive Technology & Accessibility Center, conveniently located in the Wells Library, has tremendous expertise in web accessibility and is available for consultations, trainings, and presentations.  And we in DUX are always happy to answer – or find an answer to – any specific questions you might have!

Accessibility is Important for Everyone!

After attending a training workshop on accessibility, I left with a new appreciation for the importance of web accessibility.People with disabilities, affecting their sight or aspects of their lives,  use screen readers to enjoy their online experience. So many people use the internet that it’s widely accepted that everyone is online, staring at Youtube videos of cute kittens and birds jumping on paper towels.

But there are people who use the computer without a mouse, or even a monitor when they check their Facebook or email. Creating websites that are easily accessible for everyone, regardless of disabilities, should be an important consideration when designing a website or maintaining sites for organizations. There are legal implications for not having an accessible site, outline by the Americans with Disabilities Act and section 504 of the Rehabilitation Act of 1973, which specifically applies to schools of higher education. Online discrimination is unacceptable, and taking acceptability into consideration is  important to avoid this.

Beyond the legal implications, I think keeping accessibility in mind is just good practice for web development. With HTML 5 in full swing, giving semantic meaning to your code not only makes screen reader users much happier, but it also affects your site from a Search Engine Optimization standpoint, allowing Google crawlers to pick up on the intended meaning of content and reflect that in your ranking on Google searches.

The lecture I attended outlined what the Assistive Technology and Accessibility Center (ATAC) at IU considers the top ten most important considerations for accessibility when building a site.

screenshot of JAWS for Windows screen reading software
JAWS (Job Access With Speech) a screen reader software package available at IU on ALL IU STC Lab Build Workstations and on IUanyware

They are:

  • Text Language 
  • Page Title 
  • Alternate Text for Meaningful Images 
  • Good Heading Structure 
  • Programmatically Labeled Form Controls 
  • Working Skip to Content link 
  • Keyboard Accessibility 
  • Meaningful HTML Markup 
  • Captioned Video and Transcripts for Audio 
  • Careful Use of Color and Avoid Sensory Dependent Instructions

I invite you to take a look at the slides from the presentation for detailed explanations of each of the ten accessibility concerns, but to I would like to focus here on a few that I thought were particularly important. Identifying your text language is easy to do an important. Web users use the internet in many different languages, and if you don’t specify what language your content is in, a screen reader will try to read the text in the user’s preferred language. This can lead to problem such as an Asian user’s screen reader trying to read English content to them in Thai, or going to the FBI website and having it read to you in a British accent (true story, the FBI’s site had a Great Britain language code on it, so a screen reader would read the content to the user with a British accent. It was mentioned in the workshop but I had a hard time finding a citation for this online, I guess the FBI was pretty embarrassed.)

Having a page title is essential, your site looks silly when you save your code as “Untitled.html” and it is especially frustrating to web users using a screen reader, since this is the first thing read to them whenever they access a site. Giving your page a title that clearly and succinctly identifies it is important because many screen reader users are using them because of visual impairments. Since they can’t see the site, having a title which clearly identifies it makes their browsing experience a lot more enjoyable.

Finally, providing alt text to images is really important for people who can’t see the images. Think about if you were describing something you saw to someone over the phone. You would include the most important details of what you saw, enabling the person you’re having a conversation with to understand the context of what you saw. Likewise, when providing alt text, you want to provide a detailed description of the image without going overboard on irrelevant details. Say you have a picture of the cutest kitten in the world. 

cute kitten with big blue eyes poking its head out of a jeans pant leg”

You want to provide alt text to your image that will give a screen reader user the gist of the image, without getting hung up on the different shades of brown on its face, or its whiskers, unless you really think these details are important for understanding the image within the context that you have presented it in. If you’re image is decorative, you can have a screen reader skip it by leaving empty alt text (<img alt=”“>).

I highly encourage anyone interested in learning more about accessibility to check out ATAC. Their office is on the third floor of the west tour in the Wells Library and they can help you make your site accessible or show you impressive demonstrations of assistive  technology, including screen readers.

Simplifying Technology: A View from DRS

tech-easy

On February 25, Tim Wu, in the New Yorker, published an article titled, “The Problem with Easy Technology.”  As I read the article, I struggled with its implications for the work we do here at Discovery and Research Services, especially with the ongoing migration of the IU libraries website.  Ease of use is our constant goal: to make the website so intuitive that users can easily locate information, navigate between useful pages, and quickly find what they are looking for.  Wu, however, brings up some very important questions about technology and the consequences of over-simplification.

Wu describes this danger in terms of what he calls “biological atrophy.”  That is, as humans strive to make technology easier and easier to use, we will lose critical skills that we have developed over thousands of years.  The development of these “convenience technologies” was supposed to make life easier and give us more time to focus on things like “thought, reflection, and leisure.”  There are many examples of these technologies that can only be seen as good – such as medical technology, photography, or even ski lifts (Wu’s example, not mine).

Wayyyy easier than walking!
Wayyyy easier than walking!

But it is also interesting to think about these challenges in terms of web design and content strategy.  Today, in the “Age of Google,” we consistently see that students, and even sometimes advanced researchers, struggle with any kind of database or webpage that requires them to do more than simply enter a search term.  Because of this expectation of finding information without much of an effort, students struggle more and more with the academic research process when it requires more than a basic search bar.  This also raises challenges for our web content strategy here in DRS.  We of course do not want to make the website difficult to use – quite the opposite, actually.  But I often wonder if student expectations for the site are impossible to keep up with.  It isn’t so much that we lack the talent or ingenuity of major internet companies; it is more about the fact that the nature of our resources and services do not always fit into this strict “Google-y” template.

As we continue with this migration, and with future projects, it will be interesting to see how user expectations continue to evolve.  Think of how much they have changed just in the past ten years!  But I guess that is one reason that we have our jobs: to ensure that our services keep up with user expectations.  I just wonder if, at some point, those expectations become too difficult to possibly keep up with.  As we continue to migrate and re-design the IU libraries website, it will be interesting to keep these challenges in mind.

If you are interested, you can read Wu’s article here.

Image-ine That: Writing good “alt text” for images on the web

As the Libraries prepare to move into our new Drupal-powered website, we are also preparing to think differently about how we use images. The new site, in keeping with current trends on the Web, will be somewhat more image-heavy than the old one. Working with our colleagues in the Advancement Office, we plan to offer guidance to help content creators find and select images that will convey the tone and “brand” our website needs to communicate while being both pleasing and informative for people using the site.

Once you’ve chosen an image, you will want to consider providing “alt text” – a text alternative to the image, stored in a metadata field along with the image (any content management system, including our new Drupal system, provides for this to be entered when the image is uploaded or edited). This text is used by people who use a screen reader to “see” the site for them, and may also be useful for people on a low-bandwidth connection (perhaps in a rural area or a developing country) or even people who are browsing via mobile device who may have images turned off to save on data charges or speed up the time it takes to load web pages. Like most design techniques that can be implemented to improve web accessibility, adding alt text benefits more users than just those with disabilities!

At first glance it may seem like a simple thing to input a few words describing your image. But like all web content (and yes, alt text is content!), it’s worth taking a moment to think about how to create this text so that it will be as useful as possible. Think first about what you are trying to convey with your image. What information does a sighted person gain from it? What is the image’s purpose? As WebAIM explains in an excellent article about appropriate use of alt text, context is super-important here. What purpose does the image serve in the context of the rest of your page? A picture of cute kittens may be simply decorative, or it may be used to describe the stages of kitten development. In the former case, you may not need to provide alt text since the image is not contributing to the intellectual content of the page. In the latter, your alt text may read something like “Two-week-old kittens whose ears have not quite begun to stand up.”

Three kittens illustrate the point about using kitten pictures.
In this case, a kitten is just a kitten.
Credit: Mathias Erhart/flickr

There are some special cases when you may change your alt text depending on context, and 4 Syllables has outlined several of them. For example, what if your image has a caption? And what do you do differently if your image is actually a map?

4 Syllables has also created a great decision tree for use in developing alt text:

decision tree - see 4 Syllables article linked above for full description
credit: 4 Syllables

Like all things related to user experience, a little thoughtfulness goes a long way when creating alt text. Take a moment to consider who’s using your content and what they’re trying to gain from it, and the effort will pay off in web content that is more accessible, more usable, more useful – in short, better for everyone!

Your Machine Should Not Make You Feel Stupid

At a recent DUX staff meeting, we spent some time talking about how to explain to laypeople (e.g., our moms) what it is we do in this department.  Someone offered this helpful metaphor: Ask them, “Do you ever use your computer or the Internet and feel stupid because you can’t understand how to do something—something you think should be easy to figure out?  Well,” she said, “DUX people make your machine or the website you interact with work better for you.  Your machine or a website should never make you feel stupid.”  I think that’s a smart way to look at web design and the user experience: Don’t forget you are not the user, that the tasks the user performs, while routine—perhaps even mundane to you—might truly be unfamiliar or confusing to the novice.  Therefore, design without assumptions.

When thinking about the user experience in web design, sometimes some of the simplest things slip our minds.  It’s always good to be reminded, those of us immersed in techy jargon and details, that we are probably not the target user of whatever it is we’re creating or trying to make better.  The target user might have little to no tech savvy, or might see the things on his/her computer screen in ways quite different from the average designer or usability tester.  Net Magazine, a really great tech magazine with lots of UX-related content, recently published a list of “10 UX Things We Remembered in 2012” for its year-end review.  Again, the entries on this list might seem like no-brainers, but they are easy to overlook the more one becomes assimilated to the back-end culture of web design.  I’ll let you read all ten for yourself, but I’ll highlight those entries that stood out to me most, made me utter a little “hmm” and nod my head in recognition.

#1: “You are not your customer.”  While the article is aimed primarily at commercial web design, most points are applicable to all design, including the sort of stuff we do in DUX (think: reconfiguring IUCAT and the IU Libraries website).  Authors Stuart Pill and Gavin Wye write: “It’s very easy to forget that your customers do not behave in the way that you would like them to . . . Even if you are working in a consultative role it’s easy to become accustomed to the way things are, and take for granted that people outside of your bubble will understand what you are trying to communicate.  Your customers have much less contact with your company and its products; therefore, they may need assistance with things that appear obvious to you.”

Which leads us to points two and three.  #2: “Navigating home.” Many users do not know how to navigate home, do not understand that clicking the site’s logo will typically take them to its home page; instead, they rely on their browser’s back button (assuming they landed first on the home page before moving on to specific content).  It’s strange to think of users not understanding what, to techie types at least, probably seems pretty obvious, but I can certainly see this in relation to IUCAT Classic, which doesn’t allow for a very user-friendly browser-button navigation experience.  One has to use the interface’s built-in navigation buttons or the “IUCAT Home” tab at the top of the page to get back home.  Thankfully, New IUCAT has remedied this, and it makes my heart happy to think there will be fewer confused and/or frustrated back-button clickers interacting with the catalog.

#3: “Country selection with a drop-down list.”  Here’s another supposedly obvious user task that really isn’t so easy.  The article explains: “We tested the checkout for a global retail site and found many users don’t use keyboard shortcuts to access drop-down lists.  Few people we observed knew that they could type a letter on their keyboard, use the arrow keys or hit enter to select the option.  Users still use their mouse to navigate and hence found long drop-down lists frustrating.”  Proposed, instead, is a “country selector,” wherein a user types into a traditional-looking search box the country he/she is looking for, and the box auto-completes with each letter she types.  From there, he/she can select from a much shorter, much more manageable list of countries.  However, to say, immediately, that this is the holy-grail alternative to the drop-down list is probably short-sighted, and defeats the purpose of point number one above.

Finally, #7: “The bar is still relatively low.”  “It’s easy, when you are surrounded by and immersed in the internet, to forget how hard some people find it to do things online,” caution Pill and Wye.  “The web is still a confusing place to some people.  Making tasks familiar by using established design patterns increases the chances of users completing these tasks, and so leaving your site with a sense of fulfillment and satisfaction.”  As a former teacher, Maslow’s “Hierarchy of Needs” was de rigueur in my education courses.  Maslow counts physiological needs (e.g., food, water, sleep) as paramount to a student’s success—that is, one cannot fulfill higher-order needs, such as self-esteem, achievement, and creativity, without first meeting those basic needs.  I think we can apply the same thinking to users of websites—a user cannot use and appreciate fancy-schmancy interactive features if the supposedly small things aren’t working for him/her.

Evaluating Accessibility

People today use a variety of platforms to access web content. It is important for the webpage designer to follow the appropriate web standards and guidelines to make this content accessible by all visitors. The number of guidelines and standards can be somewhat overwhelming. Luckily many types of automated web tools can help pinpoint problematic elements in a website. WAVE (web accessibility evaluation tool) is a great example of a tool that can evaluate the accessibility of a website.

To use WAVE, enter a URL in the input field on the homepage. The following page will display the website you entered to evaluate, along with icons and indicators about possible errors or problems. Red icons indicate accessibility errors, while green icons indicate accessibility features. I ran the IUB Libraries website through WAVE and the received the following summary:

wave3

Most of the errors were minor, but could be troublesome for those using screen readers. Each icon can be clicked for more information and documentation about the error or feature. WAVE is defaulted to evaluate the page with the CSS, but there is an option to only evaluate the HTML.

wave1 wave2

WAVE checks for problems based on Section 508 and WCAG 2.0 guidelines. Each error is explained, with reasoning for why it’s important and how to fix the problem. There is also a link to the official standards and guidelines for that particular problem. It is important to note that this tool cannot check for every error and it does not “certify” accessibility.

Web Accessibility in the Library, Part 2

Thanks for joining me again!  If you are just checking in, we’ve been discussing a lot about pie as well as some tools you can use to evaluate the accessibility of an online library resource you want to offer in your collection.  We covered heading structure, unique links, and color contrast in Part 1 and we’ll continue with 4 more accessibility issues that you can evaluate using Firefox plug-ins.

Alt Attributes on Images

Why Evaluate:  Providing alt attributes on images (literally, the alt=”something” inside of an <img> tag) puts text in place to describe the image.  This is useful for screen reader users who can’t see the image so they know why it’s included in the content.  Alt attributes on images are also useful for everyone.  In the case where something goes wrong on the Internet (I know, what could go wrong?) and images won’t or can’t load, the text from an alt attribute shows in the place of the image on the page, giving any user in this situation information about the image and why it is included in the content.

Tool to use: Web Accessibility Evaluation Tool (WAVE) (plugin for Firefox)

WAVE installs as a toolbar and is available under the Tools menu on your browser after installation (Firefox restart required).  This tool, from the WebAIM group, does a pretty good job of identifying multiple accessibility issues, including missing alt attributes on images.  Click the “Errors, Features, and Alerts” button in the toolbar and the page you are viewing in your browser will be reloaded showing various icons all over the page.  The ones you want to watch out for are icons in red.  Mouse over any of the icons and you will see information about the error (red icon), feature (green icon), or alert (yellow icon) that is indicated for the element the icon is near on the page.  Missing alt attributes are indicated by a red icon with a white diagonal slash.

Picture of pie from Wikipedia ‘pie’ entry showing WAVE icon for missing alt attribute.
This pie is sad because it has no alt attribute. Or whipped cream.

If you see these, you’re probably on a page that doesn’t even have valid HTML and the likelihood that the page is accessible has just plummeted.

Screenshot of Wikipedia ‘pie’ entry with WAVE icons.
This is your Wikipedia pie on WAVE. Any questions?

TIP:  To return to the original view of the web site without the lovely WAVE icons, use the “Reset Page” button in the toolbar (also available under the Tools menu for WAVE). Reset Page button from WAVE toolbar.

Continue reading “Web Accessibility in the Library, Part 2”

Web Accessibility in the Library, Part 1

Julie Hardesty is the User Interface Design Specialist in the Digital Library Program, a partnership between the Libraries and University Information Technology Services at Indiana University.  She is also located in Wells Library, but not within pie-throwing distance, unfortunately.  She does like pie, though.  Julie is a huge fan of web accessibility and generally making things on the Internet easy to understand and use.  She is reachable at jlhardes@iu.edu.

Would you know how to tell if an online resource offered in your library is accessible for screen reader users or keyboard-only users or users on mobile devices?  Many vended online library resources suffer from inaccessibility and, as a result, a lack of usability for anyone who tries to use them, regardless of the device used for access.  As the gatekeepers to scholarly information at Indiana University, we have the power to make choices and recommendations that will improve the access of our online resources as well as the overall experience that is discovering and using information at IU.  The following are seven ways to take stock of the accessibility of an online resource (and the tools to help you measure that stock).  Consider using these tools the next time you are reviewing a resource for purchase or recommending a resource to conduct scholarly research.  Disclaimer (or support): these tools are only suggestions – there are others available but these are the tools I like to use.

ALA Accessibility Challenge:  If you are going to ALA this month in Anaheim, California, ask a vendor or two on the exhibit floor about the accessibility of their products.  And don’t take a VPAT for an answer (it’s just a form, it does not guarantee that what they are currently trying to sell you is, in fact, accessible).  Ask about headers and unique links and form labels and color contrast for the site they have on display in the exhibit (see details below).  These are things that affect accessibility and anyone trying to sell you a web site should be able to discuss them.

Heading Structure

Why Evaluate: The list of headings (h1 – h6, in HTML lingo) is a shortcut that screen reader users can use to “scan” the page for content, similarly to how a sighted user would scan a page.  Arguably, a lack of heading structure on a page can make things difficult for a sighted user to make sense of the content as well.  If headings are considered within the content, the content is more likely to be broken up visually and the focus for the page will be more obvious.

Tool to use: HeadingsMap (plugin for Firefox)

HeadingsMap for Firefox will appear under your Tools menu in the browser once installed (Firefox restart required).  Triggering this plug-in will open a column on the left side of the browser window showing a hierarchical list of headings on the page.  Anything in red/pink indicates a heading that is out of order.  This tool makes it very easy to see the headings and their hierarchy and any potential problems.

Headings list shown in HeadingsMap for Wikipedia ‘pie’ entry.
Pie might be important here.

Continue reading “Web Accessibility in the Library, Part 1”

Accessibility Tip: Header Tags

As good information practitioners, we all know to put “alt” tags on our images and make our text legible for users with disabilities. But one aspect of accessibility often overlooked by the producers of web content is the structure of individual webpages. We’re more concerned with the alignment of a paragraph under a title than we are the association of that paragraph to the title. We create long blocks of text separated into flat paragraphs, without marking where one section ends and another begins. If we do use header tags to mark pages and sections, we think of them as style elements: they make certain text bigger and more visible. But header tags are not merely decorative: they are an essential element that denote the organization and meaning of the content on your webpages to screen readers.

If you use font styles or sizes to mark your section headers, this is what the page looks like to a sighted user:

Page Title

Section 1
Text text text text text.

Section 2
Text text text text text.

It seems nice and hierarchical, with a clearly defined structure, doesn’t it? But this is how a screen reader processes it:

Page Title. Section 1. Text text text text text. Section 2. Text text text text text.

In order to find “Section 2,” the user has to wade through the rest of the page. Since all of the text has equal weight, they can’t use the handy features of their screen reader software to scan the page quickly for a sense of its structure and contents. However, if you mark up “Page Title” as header 1, “Section 1” as header 2, and “Section 2” as another header 2, users with screen readers could read the page the same way a sighted user would.

Beyond accessibility, proper structuring of webpages takes us one step closer to the semantic web we all love to talk about. <strong> means “strong.” <em> means “emphasis.” Neither of them mean “I start a new section.” This is what headers are for!

With this in mind, make sure your headers follow the proper order when you apply them to your webpages. Another issue that arises from thinking about headers as styling elements is that people are sometimes tempted to skip over <h1> and use <h2> or <h3> because they’re smaller and fit what the designers want it to look like on screen. This makes as much sense as putting a title in the “subtitle” field of a book record because it looks prettier that way in the online catalog! If you put an <h2> tag in your webpage, you must have an <h1> before it. Then you can use CSS or the “style” attribute to modify the font size and looks, e.g. <h1 style=”font-size:120%”>.

Note: In the IU Libraries Content Manager, the title you enter for your webpage (the “page name”) will always be in <h1>. Each webpage should have only one <h1>, so begin your page content headers with <h2> and go down the line.

For more information on structuring webpages with headers, see the W3C’s HTML Techniques for Web Content Accessibility Guidelines. The Accessibility and Usability Guide for Penn State also offers practical advice and examples, with nods to other common pitfalls in structuring HTML documents.

EDUCAUSE goes mobile!

Thanks to Mary Popp and Courtney Greene for pointing out that current issues of both the EDUCAUSE Review and EDUCAUSE Quarterly focus on mobile technologies – including articles on mobile literacy, mobile teaching & learning, augmented reality, texting, and other good stuff.

There are a few articles not related to mobile here as well – I’d particularly like to draw your attention to a great article on why technology needs to be made accessible to visually-disabled students: “College is Hard Enough: Digital Technology Should Work for Everyone.”

Happy reading!