June 2011 Archives
An issue that I and other continue to ponder is why it remains difficult to attract women to STEM fields (math, engineering, science). Despite Larry Summer's unfortunate remarks, I do think that there are more women capable of participating in STEM fields than actually remain long enough to do so.
An excellent NMC keynote from Ahna Skop reminded me that there is somewhat of a culture gap between what many women might expect from a scientific career and what is traditionally expected.
The theme of Ahna Skop's talk was how she bucked the notion that she was "too creative for science". Although she is a respected biochemist, she points put that she and many other scientists actually draw inspiration from the beauty of their field. Although she is proficient in number crunching, she also includes media and visualization in her lab. In other words, part of her motivation is to make discoveries and present beautiful images of them.
This struck a chord in me because much of my interest in the sciences is based on "pretty pictures". I've always been mesmerized by images of planets, nebulae, mineral and abstract visualizations of various scientific processes. I realize that STEM isn't always about pretty pictures, but I am intrigued at how much math I do use in my crafts, and how crafts can be used to represent mathematical concepts.
Topology may seem very esoteric to a lot of people, but knitting is full of topological puzzles. Similarly quilting is full of area measurements for cutting and placing fabric blocks, and yes embroidery also requires counting, symmetry, enough topology to get those threads where you want them. As I said, it's amazing what mathematical related skills people will use if the result is a pretty picture.
It's almost a cliche that quilts are used to teach geometry, but there is a basic truth to there. I bet the women creating geometric designs in their crafts have an inner mathemetician. And the women making soaps and jellies have an inner chemist. If only the actual formulas didn't scare the bejeezus out of these ladies.
I think the other reason I liked this keynote so much was that Ahna Skop is not afraid to let all of her activities interact. How many women are brave enough to submit cupcake images to a scientific journal? And who would think to start a worm art show? Or create letters out of cultured bacteria? She did, and it's a refreshing change of page.
If you haven't seen my Twitter or Facebook post...I am very excited to announce that one of my embroidery designs won an award at the 1st NMC Science Art show. I will also take this opportunity to show off my pictures:
- http://www.flickr.com/photos/ejpyatt/4245971520/in/photostream#/photos/ejpyatt/4245971520/in/set-72157623015098055/ (Can't forget the knitting)
I always find it amazing that women who "don't do math" can do this (and knitting, quilting...).
A question that has come up on the TLT "A-Team" (that would be A for accessibility) is how to provide a simplified testing protocol. For a while, we've been trying to come up with one tool to replace the current accessibility.psu.edu Testing Protocol developed a while ago.
In a recent testing session though, I have to confess that I still fell back to my multiple tool scenario because it actually saves time. I did feel a little better that, at the Penn State Web conference, accessibility guru Glenda Sims pretty much recommended a similar protocol, but with different tools.
I'll try to explain what my protocol is, and why I think it saves time. I have to warn you though, that it does require some familiarity with HTML. Before that though, I will explain a very 2-step simple protocol which does work, but will take some time.
The Simple Protocol
Based on what the major issues have been, Penn State has been focusing on screenreader users and the hearing impaired. The simple protocol has been:
- Test key pages on a screen reader (no cheating with a mouse!)
- Test all videos for captions. Ensure that audio has a transcript
This is a solid protocol and will find almost all the errors we are concerned about. It will miss some color contrast issues and will not necessarily determine if users NOT on a screenreader can use the material with just a keyboard. It is time consuming and does require some familiarity with a screen reader, but does have the advantage that minimal HTML knowledge is required.
More Complex But Faster
However, I do in fact use more tools, to streamline testing to the main hot spots. Once I got familiar with these, I do find that the process goes much faster.
There are lots plugins and tricks that make Firefox my browser of choice (although Opera is also recommended). One of my favorite Firefox tricks is that you can select part of a page and view the code for just that selection. Very handy for zooming in on tricky areas.
For Firefox, I would install the FAE Toolbar. The FAE Toolbar not only links to some of the tools mentioned below but includes tools to quickly disable image, CSS and other tools.
The first part is to test a "typical" page and the home page on a site. I usually do this with WebAIM Wave. The report not only flags errors, but does a good job of showing you what a screen reader will read out in many areas. Specifically it shows:
- ALT Tags for all images - You can see if they are present and make sense
- Form field labels - like ALT tags, you can see if they are present and make sense
- Location and levels of headers - Proper use of headers is very valuable to screen readers
- Table structure - If your data table is missing header, summary and captions. It probably needs a redesign
The other benefit of WAVE is that you can spot WHERE you need to fix code.
This is a good way to test reading flow in a screen reader. Sometimes floats can put the last thing in the code on top visually, but by disabling CSS you will see the "true order" which is the one screen readers access.
Check the HTML!
If I see a table, image or form, I sometimes just check the code.
Check Color Contrast
An item most reports can't check is color contrast. There are tools to do this automatically, but I find that my eye can find many of the errors. Black and white - good. Dark navy on sky blue, probably good. Light gray on dark gray? Time for a check.
Verify with a Screen Reader
I still test with a screen reader when the other tests don't give surefire results. I check things like new tools (VoiceThread, NBC Learn, Google Forms....), anything requiring interaction beyond the usual HTML.
(Actually a lot of "screen reader" testing was actually done by Michelle McManus and Peggy Hoover who are everyday users of JAWS. If you have access to real users, they are your best source of information).
A Single Tool?
A new tool I am interested in checking is FireEyes from deque. This does put all the protocols I discussed above into one environment. But from what I've seen, you still have to push a lot of buttons.
One of my back burner issues for accessifying Microsoft Office docs is that, until recently, only the Windows version of PowerPoint, Word and Excal had the tool to add Alt Tags (the text that reads a description of an image or other object). This made it difficult to ask anyone on a Mac (which includes lots of instructors these days) to fully accessify their documents
No more! As of Office 2011 for the Mac, the ALT tag tool is available. To tag an image in Office 2011 (Word, PowerPoint and other Office applications), do the following:
- Click on an image to reveal selection handlebars (blue dots on the corner).
- Right click or control+click on the image and select Format Picture.
- In the "Format Picture" window left menu, select Alt Text (at the bottom)
- Enter a short Title.
- In the Description field, remove the file name and enter appropriate descriptive text as needed.
- Click OK.
By the way, these instructions for Windows Office are similar to these.
As some of you may know, the Copyright Term Extension Act of 1998 is fondly known as the "Mickey Mouse Law" because it preserves Disney's Mickey Mouse copyright for another 20 years. We'll see what happens to Mickey Mouse in 2018, but it turns out that Superman will beat him there first because the initial copyright is about to revert to the Shuster and Siegel families instead of DC Comics.
This story from Blastr describes the complex relationship though. The families will get some of the modern Superman, including his basic costume and basic superpowers and Krypton, but not the latter additions to the cannon (e.g. no Kryptonite, Supergirl, Lex Luthor). In fact, I'll be curious about the logo, because it did a get a little tweak between 1939 and the George Reeves era. The reversion will also only apply to the U.S.
The truth is that DC Comics will have plenty to work with, although they are rebooting Superman's costume (just in case), so Superman will live on to fight another day. However, it does point to a fascinating legal landscape that we are about the face. Sooner or later, even Mickey Mouse will start to come into public domain as will Superman, Spider-Man and other iconic characters.
Although it's clear that corporations will have the upper hand for a while since only small portions of each character will leak into the public domain, it will be interesting to see if they maintain the advantage. Fair Use already allows people to use these characters in a satiric way or as part of social commentary, but fans would love to see genuine new adventures in new combinations (maybe a Superman/Mickey Mouse crossover epic).
It's also extremely fascinating from a folkloric perspective. We think of modern "mythologies" as being unified narratives, but they are built up in pieces over time, just as ancient mythologies were. Now we will all get to appreciate the pieces of the legend. If Superman survives beyond this era, I am confident he won't really be the property of DC Comics anymore.
An issue that keeps coming up in accessibility discussions if how we can simplify it, but the goal remains elusive, and will probably remain so. I think there is a way it can be done, but you have to understand why it's complex in the first place.
Accessibility is Difficult Because....
One way in which accessibility differs from other technology standards is that the focus is on satisfying human needs versus machine needs. The goal of an XML standard is machine readability, but humans aren't as simple as machines. Humans are not only more complex, but also more varied and you can't just "read their spec", but have to make educated guesses about your audience. This is why issues like usability, accessibility and even learning are so thorny - it's all about the human brain.
Another challenge is that your accessibility audience is varied by design. Right now, we are focusing on the visually impaired audience on screen readers, but when video was coming on the scene in a big way, the audience in focus was hearing impaired. The truth is that both audiences need to be served along with those with motion impairments and cognitive disabilities. This seems complex, but it's the same issue that faces any Gen Ed course at Penn State which may need to serve people of all ages and from all backgrounds. It can be done.
A third challenge is the variety of technologies that need to be accessified. Ten years ago, we worried about HTML a lot, but now we have media, dynamic web services and mobile devices. Right now almost all of it is designed without considering accessibility (that's why lawsuits continually pop up).
And this leads to the final challenge - diversity in training needs. I think one issue with a lot of accessibility info is that it's geared either for techies who need to know it all, but can understand the code snippets out there or for administrators who need to understand the issues, but won't directly make the fixes. I think what's missing is information for those posting content with modern tools (the ones you don't need HTML for). There are steps these content providers need to make, but it can't be too technical or time consuming...or it will never happen.
Believe it or not, if you are working with just one set of tools (e.g. PowerPoint or video production), your to-dos are fairly small and simple. Videos need captions, some descriptions for the visually impaired and fed through a player which supports keyboard commands. PowerPoints need titles on slides, descriptions of images (preferably ALT tags) and decent color contrast/font selection.
This reminds me of the Unicode problem (foreign characters on the Web). When I began investigating foreign language on the Web years ago, I began by explaining general principles, then advising people to look up what they needed in tables.
Many, many blank stares later, I realized that people needed a way to find the specific information for their specific problem. I created pages for specific languages and additional pages just for Web masters who could handle some of the encoding theory. I don't claim to have the perfect navigational system yet, but I can honestly say I've been able to filter out information for many people fairly well.
I'm now thinking the same may be true for accessibility. Not everyone at Penn State will need to understand all of the WCAG 2.0, but we may be able to help them understand the fixes that need to be done for specific tools and maybe why it's important. The Accessibility Site from University of Minnesota does this pretty well and it's been suggested that we emulate that.
Another piece of the puzzle I'm hoping will fall in is better tools for the mid-techie. I've commented/complained before that too many tools for accessibility assume that you are a "specialist" familiar with HTML and the advanced tools of Acrobat or Microsoft Office. In reality though, "content" is being created by just about everyone, including very busy instructors and grad students. It would be nice if more tools integrated accessibility like Dreamweaver does.
And...I am waiting for accurate speech recognition and better reading algorithms from screen readers, but this requires some hardcore theoretical linguistics. Who knew.