Ramblinactivist’s Blogs:

Accessibility

The low-tech layout of the FRAW site has always been easier for assistive technologies to access; but we’re trying to make it better. This page explains the accessibility features of the blog.


From 2021, the FRAW site’s incremental update will seek to make the site’s accessibility functions better. Unfortunately, that means we have to completely redesign areas because of the way the new standards operate.

Where a page has a row of icons near the top, with an accessibility icon and a link to ‘blog accessibility information’, it has been upgraded. Pages without the link or icon are still operating under the old, ‘basic’, accessibility system.

We’d welcome your feedback on the ‘upgrades’. You can get in touch with ‘Ramblinactivist’ via: Facebook; Twitter; or, email.

This page describes how to use the site’s features to navigate more easily. This is an honest, practical assessment how the problems with assistive technology limit how accessibility is implemented, and the compromises this requires. The technical reasons for this are outlined at the end.

2. The basics

This section gives a basic summary of how we make pages more accessible:

The site uses a large text size, with a good spacing between lines, to make it easier to read. How big that is will depend upon the resolution of the screen you are viewing.

If the text size is not to your liking you can change it. Usually the size of the browser display can be increased by pressing 'CTRL' & '+', or decreased with 'CTRL' & '−'.

In general the flow of the page is linear. Where there are groups of images these will be displayed as an ‘aside’, so a basic screen reader will not read the labels or captions, interrupting the flow of the main text. Likewise, any extraneous information or discussion with be as a sidebar that will not be part of the main flow of the text.

The use of tabbing is enabled to access the links within pages (hotkeys are dealt with in the following section).

Where image maps are used these are excluded from the tab list, and an alternative means to access those functions is usually provided. Where images are used as links they will be excluded from the tab list. Instead a caption will usually be provided with a linked image, and this will be included in the tab list instead.

Also, when tabbing, the link which has focus is highlighted as a white on black box to make it easier to see.

As a general convention across the site, links are in three standard colours:

Blue links are ‘local’, linking to other resources on the Free Range Activism Website.

Red links are ‘off-site’, elsewhere in the Internet. In most cases off-site links are opened as a new page.

Magenta links may be ‘local’ or ‘off-site’ links, but to sites hosting ‘debatable’ content which some Internet providers block – such as scientific papers hosted outside of paywalls.

Green links are ‘within page’, such as references or bookmarks.

In almost all cases links will have a description in their ‘title’ attribute. Unfortunately how different technologies deal with the link text, its title attribute, and additional ARIA information, is not consistent.

We hope that this quick run-through enables you to use the pages of this site a little more easily. As the site is incrementally upgraded, this will hopefully make more of its content more easily available.

3. Keyboard access to blog menus

The focus on website design and accessibility is nearly always on readability. In fact the ability to easily navigate is just as important. This section lists the general hotkeys for the blog menus.

The design of ‘Ramblinactivist’s Blogs’ menus tries to use a consistent set of hot keys. Which key or keys you must press to activate the hot keys feature on your computer varies. Check the keys for the machine and the browser you use. Each of the five blogs, because of the different nature of what they contain, will contain extra option in addition to the common keys listed below. These extra keys are described in a separate page for each blog.

To aid navigation as simply as possible, any link that has a ‘hotkey’ associated with it states that in the title. When the mouse hovers over the link, or the screen reader reads the link title, it will list the hotkey for it. Otherwise 'Hotkey' & 'K' will bring you directly to the keyboard list from most indexes.

To remind you, the link titles with hotkeys usually state which key to use. Unfortunately not all screen readers present that information in the same way.

Ramblinactivist’s Blogs common keys:

There is a common set of keys that work across all index pages, allowing you to navigate between all five blogs:

'Hotkey' with 'A' to 'G'jump between blog main indexes.

The five ‘Ramblinactivist’ blogs currently use the same hotkeys to access the main index of each blog –

'A', jumps to the main index of The Free Range Activism Website.

'B', this is the core index for my blogs, with the latest posts from all five blogs merged.

'C', ‘The MetaBlog’, my general/technical blog.

'D', ‘Banburyshire Rambles Photo-Journal’, my blog on walking and the North Oxfordshire countryside.

'E', ‘Long Walks and Anarco-Primitivism’, a blog on lifestyle change, simplicity, and spending time outdoors.

'F', ‘An Anarchist’s Cookbook’, a blog on food, nutrition, and low impact lifestyles.

'G', ‘djnz’s hackblog’, a blog on ‘techno-Luddism’, documenting ideas for low-tech engineering and technology hacking.

'Hotkey' & 'Q'‘Accessibility page’

‘Q’ jumps to the accessibility page for that blog, listing the hot-keys specific to the content for that blog, as well as this list of common keys.

'Hotkey' & 'K'hotkeys list

Whenever possible a page will have a link to this list of hotkeys to make access easier.

'Hotkey' & 'W'‘Spoken Word’

Some of these pages have an audio recording of the text. Where that is included in the page ‘W’ will take you to the audio player embedded in the page. If the audio has been uploaded to another site on-line, it will take you to the page for that recording. To control the audio player, see the section below on ‘How to control the audio player from the keyboard’.

'Hotkey' with '1' to ‘9’select bookmark

Longer pages are divided into numbered sections, listed at the start of the page. Use number keys to jump to a specific section.

'Hotkey' & '0'jump to bookmarks list

This jumps the display back to the start of the page bookmarks list.

'Hotkey' & 'I'go to section index

Where pages are divided into multiple related pages, this takes you back to the main index for that section.

'Hotkey' & 'J'‘About the blog’

‘J’ jumps to the ‘about’ page that describes the blog and its purpose.

'Hotkey' & 'P'‘Recent posts’

‘P’ jumps to the latest posts page.

'Hotkey' & 'S'‘Saved posts’

‘S’ jumps to saved posts, or archive for the blog.

'Hotkey' & 'T'‘Top of the page’ area

On many pages ‘T’ jumps to the top of the page for the main menu, where the tabs to access the five blogs are located.

'Hotkey' & 'Z'background image

On most pages with a large decorative background image, this gives access to information about the background image for the page.

'Hotkey' & '[' (left angle bracket)copyright page

Jumps to the copyright page, listing copyright information and why these blogs use open content licences.

'Hotkey' & ']' (right angle bracket)contact page

Jumps to the contact page, describing the various means for getting in contact with Paul Mobbs.

4. How to control the audio player from the keyboard

The latest version of the web standard, HTML5, includes codes for an embedded audio and video player. Unfortunately when they designed it they never thought to make it easily accessible to keyboard users. We think we’ve found a work-around for that.

Officially this shouldn’t work. Taking a more authoritative view:

HTML5 video and audio instances even come with a set of inbuilt controls that allow you to control the media straight out of the box… However, there are problems with these controls: They are not keyboard-accessible in most browsers, i.e. you can't tab between the controls inside the native player.

Mozilla Developer’s Network: ‘Accessible multimedia’

Many guides describe elaborate means to try and control the embedded audio player, using lots of code and other programming gubbins. That’s not the philosophy of this website. We think we’ve found a way to do that using two simple, passive controls that don't require additional complex, embedded code.

Firstly, to control the player you must ‘have focus’ on it:

An image of the embedded audio player when you have focus on it, and thus control of it
An image of the embedded audio player when you have focus on it, and thus control of it

You could use the 'Tab' key to focus on the audio player.

The ‘Tab’ key requires you to work your way through the page to the audio player, link-by-link. When you have focus on it a big red border will light up around the player – as shown in the image on the right.

Or more quickly, use 'Hotkey' & 'W' – for ‘Spoken Word’ content.

To save all that tabbing, you can jump to any recorded content in the page using ‘W’. This locks the browser’s ‘focus’ on to the media player in the page. When you have focus there will be a red border around the player. (When you want to release the focus, to go somewhere else, just press ‘Tab’.)

Note that in some cases the audio may not be on this web site, or the page may link to other on-line content. In which case ‘W’ will take you to another website where the audio or video recording exists (unfortunately we can’t control how accessible that content will be).

Secondly, when the player is highlighted with a red border you ‘have focus’ on it, and the following keyboard controls will manipulate the audio player:

'Spacebar'Start/Stop

The spacebar starts and stops/pauses the player.

'Right' key – Fast-forward

Pressing the right key speeds forwards through the recording. This works whether the recording is playing or not.

'Left' key – Rewind

Pressing the left key speeds backwards through the recording. This works whether the recording is playing or not.

'Home' key – Jump to Start

‘Home’ goes back to the beginning of the recording. If the recording is playing it will play from the beginning again.

'End' key – Jump to end

Jumps to the end. If the recording is playing it will stop.

'Up' key – Increase volume

Increases the volume in the little slide control of the player.

'Down' key – Decrease volume

Reduces the volume of the playback.

'Hotkey' & 'X'Audio player instructions

This is a lot of detail to remember. Where there is an audio player in the page, just use ‘Hotkey’ and ‘X’ to jump directly to this list of instruction on using the audio player.

In most cases, below the player are links to the audio files that the player uses. You can download the audio file using these links. If you click on the link it will open in the browser as an audio file – after which you can use ‘Save Page’ to save a copy. If you hover over the link, you can also right-click and use, ‘Save As’, to save without playing it.

5. A more wordy take on the accessibility issue

The problems people have accessing technology are unique to the person. Unfortunately the solutions to that are impersonal, overly complex, and currently they do not work consistently. Technology is being used today to try and add-on functionality, when in fact it is the complexity of the content itself that is the root of the problem.

The greater technical debate over accessibility and design

Rather than rely on technology, my blogs use design to try and make the content more accessible. That’s a challenge as the type of content on my blogs range from dense blocks of text, to video, to visual images of the North Oxfordshire landscape.

The basis of good accessibility is not ‘WCAG’ or ‘ARIA’. The basis of good accessibility is the semantics of HTML design; with a logical, linear flow within the main content of the page.

Most accessibility tools use the semantics of page coding, introduced with HTML 5, to make decisions over how to interpret the content. Without that framework those systems cannot function as effectively.

The ‘rules’ for the use of ARIA state, HTML 5 semantic tags are to be prioritised over the use of ARIA labels. Only when HTML 5 tags cannot convey the correct semantic information should ARIA tags be used. Therefore if the page if conventionally designed around semantic HTML, rather than traditional block design, most of the work is done.

The most complex issues surrounding ‘WCAG’ and ‘ARIA’ are dynamic content. This is a far larger issues than just accessibility, and goes to the heart of the current issues surrounding the growing ecological impact of digital networks. Likewise the role of this dynamic content in web analytics and ‘surveillance capitalism’.

Most of that complexity can be dealt with using one strategic design decision: Generating static web content instead of relying on in-browser scripting.

Yes, content might still be sourced from databases, but most of the content displayed via the browser is a static, and therefore standardised and controllable set of data. The greater issue though is the growth in code widgets, creating dynamic content in the display. Drop-down menus, and their scripted complexity, being a major pitfall for content accessibility.

This isn’t just an issue of accessibility. The chaotic growth of web scripting is at the root of problems from privacy breaches to hackers stealing your processing power.

I can hear the screams of the marketeers and tech-developers now. I’ve basically just broken all their toys, and told them to go back to using the updated equivalent of HTML4 and JavaScript3 with server-side includes.

Realistically though, in a world pushing so many ecological limits, that’s the true issue here. The current standards for digital technology are based around the consuming habits of the top 5% to 10% of the global population. By definition, that’s not normal. And whether it’s an ecological or economic breakdown, we have to implement some radical changes to how this system works. Soon!

Since my own eye problems arose a few years ago, I have gotten sick of people asking, “why don’t you try using a screen reader”. I have used these for many years, as they allowed me to work more intensively on many computers at once. For that reason I know they do not work well, certainly not well enough for the types of work I undertake.

The current guidelines for web content accessibility (‘WCAG’), or accessible rich internet applications (‘ARIA’), don’t solve the accessibility problem. They create more complexity, which is the root of the accessibility problem. Not least because different assistive technologies do not work consistently, and interpret the same code in different ways.

As accessibility features are complex to add to sites, and as they are not implemented consistently, only the large web site providers will implement these standards. From researching how others tackle this, most small digital content providers will not implement accessibility as a design feature because of the complex and uncertain results that are likely to arise.

The reality is that ‘accessibility’ is more than just enabling support for screen readers. People with physical disabilities may not be able to use a standard mouse or keyboard. Those with visual disabilities may not just have issue with the size of text, but also its colour or the contrast.

Therein lies the problem. ‘WCAG’ or ‘ARIA’ are simply add-on labels that help to reproduce what is down on the screen. It’s a tick-box exercise; stating, ‘we’re accessible’ because those codes are included. In reality though, it is the design of navigation, and the style of writing and how that flows in the page, which is equally important to making content accessible (see box on the right). These bolt-on options cannot influence how pages are designed or written in order to guarantee that.

The standard approach to accessibility is to burn more resources, and generate more data, to try and address the problem of complexity. In 25 years of creating web sites I’ve refused to do that.

Instead the approach here is to use basic design rather than add-on technology to solve the problem. That entails not simply re-coding the pages of the site, but often re-writing the content so that its flow or detail enables the technology to support access. Too often the approach today is simply to recode existing content and then declare that the site is accessible.