Category: web

Reading View/Mode in your browser

This is a tip for users with some sight.

The Microsoft Edge and Mozilla Firefox browsers come with a built-in Reading View or Reader Mode (for Google Chrome there is an extension, see below).

Reading View takes the webpage you are looking at, with all its adverts and pretty columns, and rips out the actual text you want to read and fills the browser with it. You can even make this text nice and big, and zooming doesn’t lose anything off the side of the page so you don’t have to scroll left and right. This is great for reading larger web pages online.

You have to switch to Reading View for new every page you visit, though. It doesn’t happen automatically.

In both Edge and Firefox you look for an icon of a book that appears on some pages to the right of the webpage address (i.e. the white box at the very top where you see google.com). If this icon appears and/or lights up, you can click on it and go into Reading Mode.

Click the book icon in the address bar to turn on reading mode.

For Google Chrome you have to install the free Readability extension from the Chrome Web Store to do roughly the same thing. You get a permanent button at the top right of the window, and you have to click it and select “Read Now” to go into Reading View.

WebbIE Web Browser 4.5.1

Small but (I hope!) useful updates to WebbIE web browser today, version 4.5.1.

First, I’ve finally fixed a longstanding and annoying bug where Windows Narrator lost focus on the main text display area in WebbIE. You could observe this simply by navigating to google.com: when the JavaScript fired to put focus on the text input area, it took focus from WebbIE, and though I would put it back, and a sighted user could see the caret moving quite happily around the text area, as far as the MSAA/UIA screenreader interface was concerned it was still on the web page. Not Much Use.

Happily, though, WebbIE was on of my first significant .Net project three years ago, and I’ve learned much more since then – including how to fix this one! Focus is placed back in the text area correctly and Narrator works just fine.

Second, I’ve made the browser junk failing frames and external resources as it tries to load the page. This will probably break the display of some advertisements, and I’m afraid some page content too, but WebbIE will be much more responsive and useful. The is in line with a general approach I think is right for WebbIE now: it’s about convenience, and speed, and ease of use over trying to get every last HTML tag and JavaScript call to render in some kind of text format for the end user. WebbIE users are using it because they need it to be faster and simpler and better. If they want it to be more techie… they’re on, who knows, ChromeVox or EmacSpeaks!

WebbIE 4.5.0 now available

I’ve updated WebbIE 4 today, with some minor changes and bugfixes.

WebbIE 4 has supported the new HTML5 AUDIO and VIDEO elements for a couple of years, playing then in the page where they are found with a dedicated player control to make it easier for screenreader users – just play and stop, but that’s usually just what you need. I’ve now added ability to download and/or open the content of these VIDEO and AUDIO HTML5 elements directly in your default media player: the user just has to hit the Open button in the media player, and it will be opened in whatever is the default media handler is for your system. Note that this doesn’t work for embedded data URI elements! There are also new shortcut keys for the media player: Ctrl+P to play, Ctrl+O to open, and Space to stop.

Refresh in WebbIE re-parses the page, effectively, but doesn’t go and get the page anew. You can now press Shift and Control and R to perform a “proper” page refresh, reloading it from the server.

You can now open saved MHT files from File > Open, and I’ve added a TeamViewer download link to the Help menu for support purposes.

Finally, WebbIE no longer changes the case of URLs you type into the address bar, so if you are trying to access a web page on a case-sensitive server – like a Unix server – you’ll now be able to reach it.

ChromeVox browser extension

ChromeVox is a self-voicing browser extension (add-in) for Google’s Chrome browser. It’s designed by T.V. Ramen, the guy behind emacspeak.

It’s optimised for Chrome OS, at present (Google’s operating system that basically just gives you the Chrome browser as your desktop), probably because it is the only plausible accessibility story on Chrome OS for blind people, but it works fine on other systems.

You get a bunch of hotkeys that let you navigate around the page and a synthesized speech voice. The functionality is pretty geeky: if you’re comfortable with the idea that a web page is a hierarchical arrangement of nodes of different types, then you’ll fit right in. However, if you’ve already learned your many hotkeys for your screenreader to use Firefox or Internet Explorer, then you’re probably not going to find anything more useful in ChromeVox.

It’s maybe most interesting for Thunder Screenreader users, who can use ChromeVox with Chrome to give them the advanced geeky webpage navigation features previously enjoyed by JAWS or NVDA users, but can still fall back on the simpler Thunder features in Microsoft Office or WebbIE – and all for zero cost, since both Thunder and ChromeVox are free.

Keyboard traps and Javascript’s preventDefault

Nomensa has a good article on their blog about Keyboard Traps, or “I don’t use a mouse and the Javascript on a web page is stopping me tabbing past an item.”

Here’s the theory. If you use Javascript events and code to override the normal keyboard operation on something like a link or button then you have to check that you can still use the page with the tab, return, space and cursor keys. If you’ve blocked this, for whatever reason, your page will no longer be usable/accessible for keyboard users – screenreader or switch users, for example.

The example given in the Nomensa article, however, is an odd one. It traps not clicks but keyboard activity. So it’s a link that would open a pop-up window if you pressed a key while it had focus, and uses the Javascript preventDefault statement to terminate the key activity, blocking the tab to get to a new link.

But mouse users would not see any effect. This means it’s unlikely that this scenario will ever be coded: mouse users are generally the target audience, so the scenario is usually going to be “clicks are trapped and do something different” not “keyboard activity is trapped and does something different.”

Here’s an example: the Firefox development test for preventDefault. You can activate the blocking of normal mouse operation on the test checkbox, so you can no longer click on it to check or uncheck it. But using a keyboard you can tab past it and even check it! The development test assumes you trap the mouse click event, not keyboard events.

This suggests that the accessibility problem with preventDefault won’t usually be the creation of keyboard traps.

The accessibility problem preventDefault is that it will be used to create webpages where a keyboard user gets different functionality from a mouse user.

Most likely, this means that webpages that use preventDefault in trapped click events won’t work properly for keyboard users – for example, when you activate a link with the keyboard instead of the mouse, then instead of operating some code somewhere on the page to make a hidden piece of text visible, you trigger a navigation action.

And look, here’s an example of exactly that problem from stackoverflow: preventDefault() on an <a> tag Mouse users get to see text appear and disappear as they click. Keyboard users just get a click as the browser navigates to the page again.

What to recommend? If you must use events and preventDefault then trap both mouse and keyboard events, but make sure you don’t trap tab or cursor key presses or you’ll break keyboard users.

But better still, don’t use Javascript to break the default activity of a webpage element. If you want something you click and does something use a button, not a link!

Alt Tag HTML Tip: If you swap out your image, does the text still work?

If you’re a good web designer (or just one who cares about his Google ranking) then you’re populating your IMG elements with the alt attribute (tag). Sometimes this is easy, like when you’re describing a picture in a new story. Sometimes, however, you’re using an IMG element because you’re overcoming some stylistic problem with using plain text – in other words, you’re using an IMG for text content. A good example is on the BBC News website. Here’s the (edited) code:

<a href="http://www.bbc.co.uk"><span>British Broadcasting Corporation</span>
<img src="light.png" alt="BBC" /><span>Home</span></a>

If you’re sighted you’ll observe on the actual page that you see none of the words “British Broadcast Corporation” or “Home”, just the BBC logo as an image in the top left, and as normal you can click on it to go to the BBC home page, so it looks neat and simple. What’s the extra text for? We can surmise that if you’re using a screenreader or other AT device you might, depending on the AT, hear “British Broadcasting Corporation BBC Home”, which may be more helpful than just “BBC”. Let’s assume that’s the idea.

The problem is that in the absence of any visual positioning, and without any CSS instructions to add  spaces into the code, what you’ve actually coded when the IMG element is directly replaced by its alt attribute is this:

<a href="http://www.bbc.co.uk">
British Broadcasting CorporationBBCHome</a>

If you run that into a speech synthesizer you’ll probably hear something like “Broadcasting Corporation-buh-buh-chome”, which isn’t what you wanted!

The problem is that there aren’t any spaces in the text that results from swapping out your IMG element with its alt attribute content. Sure, the AT could guess that you wanted to have spaces, but then it’s changing your content – and you’ll quickly run into a situation where adding spaces in breaks up other words when it shouldn’t, like sites that use IMG elements to produce fancy initial letters on the first words in paragraphs. What you should do is something like this:

<a href="http://www.bbc.co.uk"><span>British Broadcasting Corporation </span>
<img src="light.png" alt="BBC" />
<span> Home</span></a>

or this:

<a href="http://www.bbc.co.uk"><span>British Broadcasting Corporation</span>
<img src="light.png" alt=" BBC " />
<span>Home</span></a>

In other words, structure your alt attributes so that your content still makes sense when the IMG element is replaced by the alt attribute content. Simple, but easy to overlook.

Demonstration of a screenreader end user browsing the web

If you’ve never observed an end user using assistive technology, or you’re familiar only with your own AT, it can be a real surprise how people operate when browsing, mailing, word processing and so on. While nothing can beat a session with an end user in action talking you through what they’re doing and responding to all your “but WHY do you do it THAT way?” questions, here’s the next best thing: a video of a screenreader user, Bruce Maguire, employing a refreshable Braille display (rather than synthesized speech) to browse the web:

There is also a full transcript of Bruce’s presentation. (Courtesy Roger Hudson at Web Usability)

HTML Tables: how fashion affects Assistive Technology

“I like web pages with frames” a screenreader user told me in 2003. “They make it easy to differentiate the navigation bar and the content pages.” Back then, frames were well into their decline as a popular HTML technique, replaced by single-file HTML pages using TABLE elements. Everything was wrong with frames, including problems for blind people – confusing back and forwards, problems of positioning the focus and so on. The new TABLE layouts were much better, right?

Well, frames are pretty much dead as a design tool, and no self-respecting web developer would be seen dead using them. In fact, we are now going through the process of ditching the successor to the frame, using the TABLE element to lay out web pages. We’re moving to CSS-based pages. And arguments about accessibility for blind and screenreader users are being made in support of this shift (e.g. “Tables make life hell for those using screen readers” or “Tables Aren’t as Accessible” or “make your sites more accessible to all viewers and user agents” to give you the top three Google results for “layout tables are bad”.) There’s even a Web Content Accessibility Guideline, mandating what an “accessible” website should do, that says “5.3 Do not use tables for layout unless the table makes sense when linearized.”

Is this true? What impact will the change to CSS have on blind and screenreader users compared to the current TABLE-based world? And what does it mean in terms of how we use arguments about accessibility to make decisions about technology?

Tables versus CSS: the technical details

Here’s why the use of TABLE elements is irrelevant to screenreader users and possibly even better than the CSS future.

Reason 1: Screenreaders handle layout tables just fine.

Tables for layout are the de facto standard, used on literally billions of web pages for over a decade. Screenreaders therefore handle them just fine. They’re a solved problem. Screenreader manufacturers do not generally insist that, for the sake of semantic purity, their users are inconvenienced by hearing extraneous and incorrect table formatting information as they browse the web.

Reason 2: Tables restrict designers to simpler layouts

Using tables means you have to segregate your page into relatively static and simple rectangles. The order of the content as it is encountered by the screenreader user has to reflect the order in which you code it, which means that navigation bars – usually left and top – generally come first. This is helpful for blind users because they can become used to “all the rubbish at the top” and come up with their own techniques for handling it, and the content when they do find it tends to be strictly linear and thus easier to use.

Compare this to PDF, where a page can hop about in terms of layout and floating text boxes and other things that confuse the all-important reading order. This kind of visually-effective design is much easier in CSS, and so will increase the complexity of web pages and hence decrease their usability for screenreader users.

CSS also permits much more variation in web page appearance during the page’s lifecycle, so suddenly you can do complex things like pop-up messages in CSS. Very Ajax, very hard for screenreaders.

Reason 3: CSS doesn’t give you any more semantics than layout TABLES.

It’s not like using CSS suddenly lets a screenreader user spot a search box, navigation bar or main content. CSS elements are arbitrarily named with non-standard tags. HTML5 might fix things – it has extra elements like NAV for navigation bar, which might actually be useful – but that’s going to be a long way off.

CSS3, of course, has a layout table anyway, so the Next Big Thing may well be – scrapping CSS for tables!

Reason 4: The implicit alternatives are “broken TABLE use” versus “utopian semantic web use”.

The latter isn’t going to happen. Most data is in PDFs or CVS. Everything else is in the tag soup of web pages. Maybe Wolfram Alpha will pull it out, but that gives one central point of reference – not arbitrary tables. Google gets information from links, not from page semantics – page semantics are too easy to game, as you’ll know if you tried using Alta Vista in 1999.

5 It should be easy to use heuristics to detect real data tables. They’ll need the extra semantics anyway.

The fact that content is laid out in a grid doesn’t really tell us that much. What do the columns mean? What’s the relationship between each item in each cell? Well, HTML gives us some extra elements which are actually useful – CAPTION, TH, SUMMARY. So a real data table is almost certainly going to use them.

Which gives us a convenient heuristic to differentiate data tables from layout tables: if it has the additional semantic elements then it’s a data table, otherwise it’s a layout table. So are we really missing semantics from the mis-use of the TABLE tag, or are we just missing actual non-layout TABLE elements from the Web?

7 TABLEs are relatively consistently and widely supported.

This means that people with alternative browsers are more likely to make sense of your layout, and the DOM for your access technology is simpler to parse and use. Known, older technology has better support from AT vendors, who always lag a few years behind, and from trainers and users and experts who need to build up techniques and approaches for new ways of doing things.

8 TABLEs scale better when you zoom the text.

CSS coders make assumptions: TABLE coders make assumptions. CSS assumptions don’t include people needing to zoom pages 400%, 1000% to read them. TABLE assumptions don’t include that either. However, because of how they are implemented in every major browser, and because they are simpler and lay out more simply, tables work much better when you zoom them up. Sure, you get a side-ways scrolling bar, but you don’t get overlapping text and columns squeezed to one character and rendered entirely unreadable.  Try it yourself with a table page and a CSS page.

6 Finally, CSS is harder than TABLEs: it’s a status symbol. The wasted time producing the same visual effect could have been used for accessibility.

First there were FRAME elements, then TABLE elements, now CSS. Professionals need a way to argue to their clients that their work is better than others: the ability to use hard-to-implement CSS is a form of display, a status symbol like a peacock’s tail. “Choose me, I can do this really hard thing! That means I’ll do a really good job of your site!”

What this all means for screenreader users and AT practitioners

If TABLEs are better than CSS, then what’s going to happen next? Can we fight it?

No. Let’s be honest: CSS is in, and layout tables are out. There is no way we’ll go back to TABLE use. The lesson to learn, therefore, is not that tables are better or worse. The lesson is that fashions and politics apply to coding and technology as much as they do anything else. Don’t believe the hype.

What we have to do is try, this time, to not drop the ball. CSS is part of making the browser environment a fully-fledged operating system, which means vastly increased complexity for the web page over the static text-based document of a decade ago. There will be decisions made about technology and support for screenreader users of these pages a-plenty: don’t leave them until the application is finished, because it never will be. The web moves too fast. Investigate HTML5 and WEB-ARIA and using your site without a screen or a mouse or the ability to click-and-drag.

Finally, coming full-circle back to our layout TABLES: if you want to help screenreader users, don’t waste your time replacing TABLE layouts with CSS. Wait until HTML5, and add the existing useful page semantics in HTML4, especially for your data tables. And make you funky AJAX sites work somehow if you turn off Javascript and pull out your mouse, and you’ll be doing the Right Thing.