accessibility issues

content-oriented site

This is a description of how accessibility issues are handled on this very website, and how I have reflected on such issues over the years. Whether you experience zero 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 complicating 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 illustrations to the text is left out if/when a 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) – with a 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 navigation. There are no drop-down or fly-out menus on my site.

A “skip to navigation” 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 navigation” from anywhere on a page.

A “homepage” 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 are 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 descriptive 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…

(Oldest pages on site use Javascript for the show/hide functionality, while newer pages are given a CSS-only solution.)

On many pages the Addendum contains potentially interesting additions to the main article – including larger images, so it may be 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

single-column for narrow windows/screens

“Small Screen Rendering” mode is the basis for mobile devices. One-column layout tailored to make the most out of small screens – below 643(px) in width, or reduced browser window-width on any screen.

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

On top of pages you will find the expected gunlaug.com “homepage” link, and a “skip to navigation” link.

In lower-right corner of the window/screen in “Small Screen Rendering” mode, you find the semi-transparent circle with “#nav” written at an angle to make it stand out when layered over regular content-text, that acts as an always present – fixed in place – “skip to navigation” link from anywhere on the page.

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

The reason I call it a “fat footer” is because the Addendum section, which is always open in “Small Screen Rendering” mode, is an integrated part of the footer. This makes the footer on my pages much “fatter”, or rather taller, than what is normal for page-footers found on most web sites.

The Addendum section is where all the additional content and/or “boring obligatory stuff” is placed. Type and amount of content in Addendum does, as mentioned earlier, vary a great deal from page to page.

observe mode-switching…

Switching between one column and two column mode/styling, is based on available window width and zoom factor, not on device-type and/or actual 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) – using keyboard

Pages are organized to be “user friendly” for basic navigation using any method and device, but it isn't a fine-tuned system, and especially some new and experimental design features may be difficult to access via keyboard alone.

The basics that get tested, is element (link / checkbox) tabbing…
Tab / Shift+Tab
Enter / Space
… which cover most in-page navigation.

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 navigation”.
Second last link on page is to main page – the “homepage–.

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 seem to 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 can not 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 640(px) 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 reasonable 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.

sincerely georg; sign

Weeki Wachee 01.feb.2011
last rev: 22.sep.2023

side notes.

resources

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

Based on my own testing of browsers as pr. 2020, I have switched to Vivaldi for all my daily surfing, and also base all my web related production and debugging on that browser. 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.
Using only one web standards conforming browser for testing, is not much of a problem these days, since almost all new and regularly updated browsers are built around the same few rendering engines. Visual differences are therefore minimal.

Apart from Vivaldi, the only browser I use somewhat regularly 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 others 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.
– Google: Webmaster Guidelines

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…
… and for most pages even my graphic browser's “Reader View” with image-loading set to “Never” will tell me most of what I need to know.

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, and, not to forget, the all-important EndUser-support.

Older versions of any browser do not 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 somewhat acceptable without styling. Those who want to see a progressively designed web page/site, with all its visual styling intact, better use, or upgrade to, a browser that can deliver.

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.

As quite a few images on site are all text in the form of quotes or whatever, I make use of off-screen techniques when necessary. Then the image-content is reflected, or copied, as initially hidden text in the flow right after the image.
Images with off-screen or otherwise hidden text, are marked with a visual overlay; a [T] or [+], or an outline that shows up on :hover, and an alt-text hinting at the following text. Such a combination should give all visitors info about, and access to, the off-screen text. What does not show up on :hover alone, will show up on :active.

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 interacting 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) in those few cases 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 hardware and software. 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.

For more information, see W3C: ACCESSIBILITY (my recommendation) .

external resources…

famous last words…

When all is said and done, it won't make much of a difference. It all will turn out backwards anyway, as if nothing has ever been said and nothing has ever been done.
Do not bother to ask “why”, as regardless of answer nothing will ever change for the better … and it really does not matter.