accessi­bility issues

content-oriented site

This is a description of how accessibility issues are
handled on this website, and how I have reflected on such issues. Whether
you experience no problems, or have special needs while surfing the web, this
guide and description is written for you.
Access is for everyone … me included.

a simple approach

I don't believe in compli­cating things for myself or others.
So no matter the design, the content flows naturally from top to bottom in the
source-code – linear or sequenced like in a book. In my opinion,
naturally sequenced content-flow is the basis for easy‐to‐access
documents, so it is a good place to start.

Plain text, grouped under suitable headlines, is used to describe all
about any subject it makes sense to describe. Thus, nothing but visual
illustr­ations to the text is left out if/when page is accessed as
“text only”.

The flow gets broken by me signing off the page after the main part of the
article, followed by various side-notes before site-navigation, and Addendum at the very bottom. To me this is the most logical
order, and I am pretty consequent throughout the site so it should not
cause in‐page navigation problems for anyone.

navigation (1) – mouse

in graphic browsers, on wide screens

Here we have my “mirrored L” two column layout, with navigation in
page footer followed by an Addendum.

Never mind how it is made to look that way. It is a pretty typical
responsive layout/​design, for just about any condition on any screen.

A double row of button-like links in footer on every page, makes up website
navi­gation. There are no drop-down or fly-out menus on my site.

A “skip to navi­gation” link is provided in top/right corner on
all pages, for those who do not want to manually scroll down to navigation in
the footer.
The “tail” of this link pops up when mouse-pointer gets near the bottom
of the visible page, making it easy to “skip to navi­gation”
from anywhere.

A “home­page” link is provided in upper left corner on all pages.
Click on the site-name, and you are brought to the “welcome” page on
site.

main site navigation

All site-sections have “Table of Content” (ToC) pages on
top. These ToC pages together cover navigation across the entire site.

To go to the ToC page in the section you're in, click on
“content” button in top row in footer on whatever page you are on.
To go to ToC page in another section, click on the desired
“section” button in second row instead.

link relations coded in

A basic set of link-relations is coded in in page-head in all
pages – out of sight in most browsers that is.
Some browsers make use of these link-relations to pre-fetch pages and data. Other
browsers make them available as an extra set of site navigation. Other browsers
again, just ignore them.

in-page navigation

All content, menus and aside‐stuff is grouped in suitable chunks under
headlines, which should make it easy to navigate around on individual pages.

observe the addendum

I most often add an Addendum to bottom of pages, with a “show/hide
Addendum” button below navigation in page footer…

On many pages the Addendum contains potentially
interesting additions to the main article – including larger images, so it
is well worth looking into. On some pages the Addendum only contains pretty
basic site-related (small text) stuff, and on some pages the Addendum is simply
not populated.

navigation (2) – ssr

on narrow screens and small devices

“Small Screen Rendering” mode is the basis for mobile devices.
One column layout tailored to make the most out of small screens – below
500 in width, or very narrow browser windows on any screen.

One column graphic layout can also be referred to as
“accessibility mode”, as what we all see on our screens is more or
less identical to the linear way most Assistive Technology (AT) software work
their way down web pages.

At top of pages you find the expected “home­page” and
“skip to navi­gation” links.

Two lists of button-like links on every page, make up website
navi­gation. These are found in the “fat footer” below all
ordinary content.

The reason it is called a “fat footer” is because
navi­gation links are followed by the Addendum
section – which is always open in “Small Screen Rendering”
mode. This makes the footer on my pages much “fatter”, or rather
taller, than what is normal for footers found on pages on most web sites.

The Addendum section is where all the additional content and/or “boring
obligatory stuff” is placed. Type of content in Addendum varies a great
deal from page to page.

observe mode-switching on narrow screens/windows

Switching between one column and two column is based on available window
width and zoom factor, not on device type and/or screen size.

As “Small Screen Rendering” devices – smartphones and such
– are as often viewed/​used horizontally as vertically, users should
be aware that mode-switching between one and two column layout may take place
when going from one to the other orientation.

navigation (3) – keyboard

Pages are organized to be “user friendly” for basic keyboard
navi­gation, but the system isn't fine-tuned (yet) and especially some new
and experimental design features may be difficult to access via keyboard alone.

Tabbing order is natural and sequential, and, apart from that a couple of (mainly
irrelevant) links are taken out of the tab-order, there are no changes in priorities
made via tabindex or in other ways.

The links on all pages that may matter most to most visitors,
are…

Last link on page is “skip to navi­gation”.

Second last link on page is to main page.

Visually and functionally the reaction to keyboard :focus does
for the most part mimic mouse-:hover, but there are a few differences.
In places where :focus is indirect, the on-screen indication for
tabbing is not perfect.

As keyboard tabbing will follow off-screen positioned links and checkboxes,
on-screen indication may be missing and page may move erratic in some cases.
I will try to remedy some of that, but sometimes there are “conflicts
between interests”.

page-zoom, text-resize and auto-adjust

All major browsers can zoom pages and/or resize text. Thus, if the default
text-size is too large or too small for comfort on your screens, you can adjust
in your own browser.

I have made reasonably sure nothing gets lost or too much out of wack
when these pages are subjected to text-resizing up to 200% of browser default.
Beyond that I may have tested, but
cannot guarantee that everything will line up and appear perfect everywhere.

Lower page-width limit depends on your browser. Modern browsers
will allow the page to shrink in to around 500 in width for “two column
layout”, auto-switching to “one column layout” below that
width. When you are zooming or resizing text, or whole page, in your browser,
the exact point at which switching takes place changes with the resizing factor.

accessibility first, foremost and always

For the most part common sense and local testing are my guides towards
reasonably good access to content and functional site-navigation, for
a simple document-format website like this.

My basic rule is that if everything makes perfect sense and works as intended
in my copy of Lynx –
a “text only” browser, I can not be too far off. If testing
shows that it makes perfect sense in graphic browsers too, then even better.

The above may sound like an oversimplified recipe to some, but according to
friends in constant need of well‐organized and easy accessible web documents,
my “linear format”, works fine. I hope they're right, as
I will myself also probably need well‐prepared and accessible web sites
as much as anyone, one day.

it's all here.

Next to nothing is added to make this website more accessible. Nothing is
simplified to make this website more accessible. Nothing is reorganized or
removed to make this website more accessible.

In short: it is all here, appearing and behaving as it would if accessibility
wasn't an issue.

side notes.

resources

Most visitors use graphic browsers, so naturally I design in one
and check the result in all major graphic browsers.

Opera has been the
most accessibility‐oriented browser for more than a decade, and has
in my opinion the same position today even if the new engine is far from as
powerful in this respect as the old one was.

As a consequence I produce and debug all my designs in Opera,
and use Opera for all my daily web surfing. All other major graphic browsers, and quite a few minor
browsers, are run locally from time to time so I can test their performance
on mine and other people's web work.

Apart from Opera, the only browser I use somewhat
regularly for surfing is Lynx.

In my very personal opinion: most web designs – and I am not
excluding my own – look so much better in Lynx. Some even work
reasonably well…

Checking how web pages work in Lynx also has other advantages, as what
Lynx can “see” all other can see, and what is hidden from
Lynx is likely hidden from many others, including from search engines.

Use a text browser such as Lynx to examine your site,
because most search engine spiders see your site much as Lynx would.

Comparing and combining what Lynx can do with what comes up in graphic
browsers, provides the conscious webmaster with loads of useful information for
free.

In cases when I don't have my own copies of Lynx
available, Lynx Viewer comes quite handy.

browser support and CSS

CSS naturally
controls layout and carry design theme(s) across various media and devices.

As CSS is a way to “suggest” how a web
page should appear, it is like building “castles in the air” in that
it relies entirely on browser-support.

Older versions of any browser don't support my extensive and in
places a bit complex use of CSS2.1 and CSS3
fragments well. But, with new browser versions available for free for all
operating systems in regular use, I honestly do not see lack of support for obsolete browsers as an
accessibility issue.

CSS can be turned off if a browser can't handle it, and my
sites are (as I have hinted at a few times) designed to work well
without styling. Those who want to see a progressively designed web
page/​site with all its visual styling intact, better upgrade to
a browser that can deliver.

At the time of writing/​updating this article
(February 2014), latest versions of all major browsers, and quite
a few a bit older and/or alternative browsers, render this design well
enough for comfort.

decorative images

Some say all decorative images should be defined in and confined to
CSS, so as not to add unnecessary clutter to the content in
source-code.
I kind of agree with the idea as such.

However, if I followed such a “rule” I would soon
end up with some enormous stylesheets and not save much if anything in
source-code. Certainly would not make my pages more accessible.

So I will continue my practice and include decorative images with empty
alt-attributes in source-code, until the day comes when standards,
all major browsers, and assistive technologies, provide and support better
solutions.

regular images

Most regular images on this site have empty alt-attributes too.
This is mainly because whatever they present is expanded upon in the surrounding
text, and I see no point in presenting double descriptions to those who can
not see images.

All content gets checked in “text only” browsers like Lynx
(see above), and alternative text added to individual images if I find it
necessary for complete presentation. This means the alternative text must fall
as seamlessly as possible in with surrounding text, almost regardless of what
the image shows.

All images are styled to be resized down or clipped in browsers,
to fit in available space. Of course all images look best at original size, but
this being a flexible/​responsive layout/​design, and that
I do not want to replace a lot of images with copies tailored for
different column dimensions, I find that compromising slightly on image
quality is acceptable.

avoiding overkill

I am constantly aware of the possibility for “overkill”
– trying to cut through and fix all shortcomings and weaknesses across
browser-land and assistive technologies from the designing/​coding end.
I have seen quite a bit of that around, and I do not want to
become trapped in a web of “uber-clever” solutions.

I have seen plenty of the opposite too: designing for one or a few
browsers' peculiarities and ignoring all else. This is an old recipe for
disaster that should have died with IE6, and one that I wouldn't
dream of buying into.

Deviations from logical sequencing in source-code, and endless
“fixes” via use of style, scripts etc in order to make one or
another browser work, is not recommended. The reduced logic tends to spread,
maintenance can quickly become a nightmare, and content can become very hard to
access.

In the end the amount of deviations and lack of logic throughout
a layout/​design, can have disastrous effects both in unchecked
browsers and for alternative ways of extracting content and interact with web
documents – even prevent some software from working properly or
at all.

assistive technology

There are lots of solutions built into browsers – directly or via add-ons,
and there are assistive
technologies for people in need of even more efficient and better tailored
solutions for accessing websites, read and work with documents, etc.

Apart from including appropriate aria-(role) where
I have found that advantageous in pages written in later years, I have
done next to nothing to improve support for screen readers or other
assistive solutions.

I have not found uniformity or agreed-upon recipes
for how to improve things accessibilitywise across the board, except for the WCAG
recommendations. That isn't much to act upon beyond what I would
normally do for all visitors anyway.

Producers of assistive technology have to make it work for real-world websites
that are organized, coded and otherwise populated more or less in accordance with
existing standards and WCAG
recommendations, or they should fix their inadequate products or pull them from
the market.

Producers of assistive technology should not expect web
designers/​coders to “fix” their products for them.

Same goes for end-users' set-ups and how they use their hard­ware
and soft­ware. I don't know more about what kind of set-ups people with
special needs have or how they use it, then I know about what people without
special needs have or use.

If some have made poor choices, or poor choices have been made for them, then
problems that show up because of this should be fixed at their end.

It would be “extreme overkill” if web designers/​coders even
tried to code to solve individual end-user's problems, apart from that it simply
cannot be done without the risk of interfering with other end-users' more
well-working set-ups.

make it work at your end

I am in no doubt that anyone who can use some form for navigation device
along with input and output devices, can make use of any somewhat logically
organized website.

How to go about it without using the regular set-ups and devices
with keyboard, mouse, (touch)screen, speakers and microphone, is something
I know very little about.

I have blind friends who regularly go through web pages and entire
sites much faster than I can, and they are not missing a thing. How they
manage so well is way beyond my understanding, but I know it has taken them
quite some time to learn how to handle their equipment and to find their way
around on the world wide web.

navigation

choose a section?

addendum

design for access on all devices

Access for all does not cost extra, except when a site does not provide next to equal access for all from the start and have
to correct for that blunder later on.
The norm is that site-owners lose money by ignoring accessibility issues, through loss of sales and cost of site-upgrading to
“fix” issues. Those site-owners who choose to do it right from the start, save money in development (as it is so much
easier and quicker to design with web standards and accessibility guidelines, than against and/or around them) and earn
more by getting, and keeping, more happy and paying customers.

Yes, I have heard all arguments along the lines of “we can't afford the extra cost involved in catering for disabled
people” and ”blind people don't buy our products anyway”. They are all false, and I have yet to hear a valid,
business-based, argument against providing next to equal access for all – now.

In my experience there is always much to gain – regardless of type of site – by designing for all end-users on
all devices from the start, compared to some form of convoluted idea of designing only for the most used screens/​devices.

The range of screen-sizes and types/​variants of devices in use, is an everchanging variable. Thus, trying to limit the amount of
design-work and cost by targeting only a limited selection of the increasingly wider range of devices, is likely to hit wrong and
result in you having to start over again in a short while. Not good, unless you have unlimited resources and don't care how you
wastespend them.

If you primarily (or secondarily) aim to design for mobile devices, and don't want to spend time on making your designs work
for people with disabilities, you should read the WCAG guidelines for Making a Web
Site Accessible Both for People with Disabilities and for Mobile Devices to see the overlap in interests and techniques. By
covering all from the start you will actually save time and work, which of course often means “saving money”
— important to those who work on a budget.

Visibility alongside the multitude of sites that present similar products and services across the web, will to a large degree depend
on “ease of access and use”, which is another term pointing at accessibility issues. That “searchability” and
“accessibility” to a large degree also depend on the same factors is often overlooked, resulting in sites that are hard
to find when potential customers are searching. Being hard to find is obviously not good for business, and improving accessibility and
thereby searchability always works better and costs less than hiring someone to perform search engine optimization (SEO) on a site.

I do by choice not perform SEO in any form on web sites, but all sites I am involved in perform well mainly because content is
logically organized and accessible to everyone. This is just one of the many advantages that comes for free for accessible sites, and
I certainly do not mind getting something like this for free.
More here: Essential Components of Web Accessibility.

we all need accessibility‐support, now or later

Inclusive web development … yes!
I couldn't care less about all that is written about how to provide “access for the blind”, “access for the disabled”
and all the other individual “needy” groups that you can think of. Such “who need what” divisions are not for me.

For instance: an able-body person with 20/20 vision may want/need intelligible speech output and keyboard navigation in certain situations.
Others with fully functional senses may want/need to turn off images and other types of included media – sound for instance – in
certain situations. “Conditional deviations from the rules” are perfectly acceptable to me, and nothing important should get lost
when they are applied.

In my opinion: accessibility is for all, without unnecessary grouping or restrictions as to who what part is for, and my job is to
make my stuff work for all whether I release regular articles, media-heavy stuff, or mainly interactive documents.

Use a compliant browser and assistive software, and you can be sure I will support it the best I can.

Proprietary solutions … are not my business.
Some pretty smart new devices and software are clearly made for specific user-groups and uses. That's fine with me – I welcome
smart newproducts, but I am not lifting a finger to make anyting I produce and release work on devices and software that require
proprietary code/​solutions.

Device and software developers should make their web-able products comply with existing web standards, or work to expand those
same standards. That way I and others can rely on standardized code and solutions to support the devices and software in question
without messing up what already works based on standards.

My approach is that if products meant to be used on the web deviate seriously from web standards, I just ignore them – access
or not. I am not the least interested in finding out how smart and/or trendy new gadgets are if they won't work along with best
practices in web design today.

In short: I don't aim to make my site work on every device and in every browser that enter the market, only the reasonably
compliant ones.

know your browsers — inside/out

Web designers/coders should know how browsers work, and make sure they are not corrupting potentially useful functionality.
You may not need any extra functionality now, but you may one day and you can't really disable functionality in end-users' browsers
anyway – only mess it up. Thus, it makes sense to know what they are and how they work.

As a general rule: browsers are not destroying designs by adding functionality, they enhance designs for end-users. Web
designers/​coders should leave such browser-specific enhancements alone and just make sure designs don't break when subjected
to them.

Have you heard designers/​coders complain about the dotted outline on active links in Firefox? Well, if you have visited
a designer-list/​forum in the last couple of years you probably have. Now, leave that browser-induced outline alone, or else
someone will come up with a way to enforce outline across the board – it is really easy.

As web designer and/or front-end coder you should know your and other people's browsers well enough not to mess with their basic
functionality. All will work, and appear, so much better then.

Browsers can still resize text.
Web designers/coders must keep in mind that regardless of the now wide-spread page-zoom functionality, all major browsers have
one or another form for font-resizing functionality built in. Documents released on the web should be able to take a fair amount
of font-resizing – at least 200% of browser-default (which isn't necessarily the same as design-default) – without
becoming unintelligible.

If/when designers/coders try to “overcome” or “negate” font-resizing, they nearly always just make their
designs weaker when font-resizing kicks in. No way to avoid browsers' font-resizing, so better learn to live and design with it.

Personally I have used page zoom while surfing for the last decade or so, as my preferred browser – Opera –
were first out with that particular functionality. That Opera also resizes text independent of page-zoom is something I have
always taken into account when designing / coding, and I do make sure it all works in other major browsers too.
Remember that IE still completely ignores font-sizes declared in web pages if end-users want it to. It is an accessibility-option…