23 July –
If you wonder what has happened before we got here, you may want to read this. It goes back all the way to 1999, that’s a whopping 24 years ago. Most of that rather long article (almost 2700 words, TL;DR?) is about browser bugs – or at least I think that’s what they are: not features, but bugs – and about what are possible work-arounds.
At the end of the article I had
arrived at a solution
that avoided the bugs, and had both text and navigation horizontally
centred on the screen
(or should I better call that ‘vertically centred’, maybe?), not
glued to the left
edge like before. I achieved that by using position:static
for the text part, position:sticky (i.e. sticking to the
bottom) for the navigation links, and margin:auto to
centre everything.
However, there were problems with this, especially on tablets and smartphones. (I will call them phablets henceforth.) There is a trade-off between space and comfort. I want to keep as much of the space available (often limited, especially on smartphones) free for the text. On the other hand, the area for navigation links should be large enough to show all of them, or allow comfortable scrolling. As it was, the navigation area was too small for that, which was aggravated by the fact that phablet OSes have their own task bars popping up in the bottom of the screen. Android has, anyway.
Strangely, the user can’t chose to make the navigation area taller. Its height must be fixed at design time. With the now obsolete and often mocked frames, that was possible! You can still see and try that in the old demonstrations of my site’s front page: 1 , 2 , 3 , 4 , 5 , 6 , 7 . There, all the borders can be repositioned with the mouse, which resizes the frames.
In the early days of my web page building, I used a Dutch book Webdesign in de praktijk, by Peter Kentie. I learnt a lot from it, and in 2002, I recommended it.
Now that I page through it again in 2023, and reread parts of it, I don’t find it a good book at all: rather chaotic, and many things are mentioned, but not clearly explained in detail. There is much what, but not enough how.
I have a memory of finding a way to code drop-down menus for navigation, but I can’t find it right now. It should have been in the section about Dynamic HTML (DHTML), written by co-author Peter-Paul Koch. DHTML was defined there as HTML with CSS, which is modified dynamically using Javascript. That required knowledge of the DOM (Document Object Model), of which, says the Dutch book (Edition 5, page 379) no less than four variants existed.
In those days browser wars were raging, with key players Netscape and Microsoft. So as I understood it from the book, I would have to test which browser my visitor was using, and activate programming code tailored to that browser and corresponding DOM, just to make a standard menu that non-web programs had had for at least a decade. Not nice. This is one of the reasons why I preferred simplicity on the web, and restricted myself to section headings, text, lists, hyperlinks, and tables. No pop-up or drop-down menus.
The browser wars are over. These days in practice only three browser code bases remain: Gecko (used by Firefox), Chromium (Google Chrome, Microsoft Edge) and Webkit (Safari, Epiphany). And all three do their best to closely follow the standards defined by The World Wide Web Consortium (W3.org). So it should be possible now to code once, for all browsers, including menus.
I googled and found this, “How
to Create an HTML Dropdown Menu [+ Examples]”, by Anna Fitzgerald.
The first example, using label, select, and
option, works well, but I wonder: how does it interface
with the rest of the code? When I choose one of the dogs’ names, nothing
happens. I tried to put hyperlinks in the place of the names, but that
didn’t work. Are you supposed to write Javascript that reacts to the
value set by the option? Or use CGI? I don’t
like it. Next.
I continued at
“How to Make a Hoverable Dropdown Menu”.
The idea here is to show a button, but give the actual menu texts and
links the property display:none, so they are invisible.
They only become visible (display:block) when the user
hovers over the navigation button with the mouse. Or on phablets:
tapping the button works as well. Such devices have no mouse.
That works well. But there are problems.
The web article I linked to, by Anna Fitzgerald, mentions accessibility, and I agree that that’s important. When working for Nixdorf between 1985 and 1990, I had a blind colleague. I learnt a lot from him, about Unix and Unix system administration, by watching the screen of his PC (an XT? AT?), while he typed and read the braille on a mechanical device, controlled by the PC. Other people in that work environment used 1200 baud terminals, not PCs.
He is no longer alive, he died young. Legally, in the European Union, according to the GDPR (General Data Protection Regulation), the dead have no privacy, so I can mention his name: Wim van Eerdt. I mean it as a tribute.
A way for the visually impaired to use computers, other than braille, is to have text read aloud. Using Linux Mint and Firefox, I found and tested plug-ins Pericles Screen Reader by Alexandru Calin, and Text Read Aloud, by LSD Software. Both have rather bad quality, mechanical voices. But more or less understandable.
Here I discovered the problem: Text Read Aloud doesn’t read the navigation
links if they are initially set to display:none, as in my
Demo 03. For that reason
I modified the approach, as shown in
Demo 04 and
Demo 05. Eventually I
implemented an improved version of Demo 05 site-wide. Not perfect,
but the best I can do right now.
One would expect that at W3.org they know how to do it, and how to do it well. However, in my tests, the menu texts on that site, or those at the top of the page anyway, were not read aloud.
The same was true of a site someone mentioned on Usenet, as an example of how good menus can be implemented. That is, the navigation texts were ignored, but were ‘seen’ by Microsoft Edge under Windows 10.
I installed ChromeVox as an extension to browser Chromium under Linux Mint. (Really Chromium, not Chrome.) From then on I heard a lot of funny squeaks and sounds I don’t know how to describe, when I went from window to window, or from tab to tab, etc. But no text was read aloud. Later on, I found that the magical key combination Ctrl-Alt-Z should activate that. But nothing happened when I pressed that.
Later in browser Chrome under Window 10, I did hear a voice reading
the text. It was in Flemish (is my Windows installation in Dutch?
I think so), but it didn’t adapt to the language of web pages, even
though they are clearly indicated, e.g. lang=en. In
the options of ChromeVox, I could activate an American English voice,
but then, while ChromeVox read a page in English, I still also heard
some Dutch words, pronounced as if they were English.
E.g. Venster (that means Window), Waarschuwing (that’s
Warning in English; where does that come from? There is no such word
in the web pages I tested), and Kop 1, which is Dutch for
‘Header 1’, for text between <h1> and </h1>.
Shouldn’t that have been read in English, when visiting a web page written in that language? Or in Dutch because of the Dutch Windows installation, but then by a Dutch or Flemish voice, not the American voice. But maybe my thinking is too logical. Or illogical. Not the first time I notice Google is thinking in ways that I don’t understand.
Another problem is that this ChromeVox in Chrome under Windows read only one header or paragraph at a time, then stopped. Ctrl-Alt-Z did nothing. I could get a next paragraph read, by clicking it with the mouse. I can see and hear. But I was testing accessibility for the blind and visually impaired here. Can they work with this software? How?
The Tab key did reach the menus, at least in my demo 01, but not the other texts.
Would all of this work better, i.e. acceptably, on a Chrome Book? As I understand it, that is a computer equipped with a special Linux version, and with all the necessary software pre-installed. I don’t have one, prefer not to buy one, so didn’t test it.
Microsoft Edge (based on Chromium) under Windows 10 has read-aloud software built in as standard. There is a choice of many human sounding voices, also with regional accents, in many languages. They sound good.
Ctrl-Shift-U is the keyboard shortcut for activation. Reading automatically continues from one paragraphs to the next.
However, invisible menu texts aren’t read here either.
Here is a tabular presentation of my test results, focusing on whether or not menu items were included in the text that was read aloud.
I left out ChromeVox, because sadly it was in fact completely unusable.
| Web page | Pericles | Text Read Aloud |
Edge built-in |
| Demo 01 | N | Y | Y |
| Demo 02 | N | Y | Y |
| Demo 03 | N | N | N |
| Demo 04 | N | Y | Y |
| Demo 05 | N | Y | Y |
| W3.org | N | N | N |
| Vancouver Bach Family of Choirs | N | N | Y |
Some notes:
Pericles also missed the non-menu parts “Get involved” and “Latest News” in W3.org.
Text Read Aloud did read “Get involved”, but not “Latest News” and the menus of W3.org.
In the Bach Choir site, Edge did not read the navigation items at the top of the page, but did ‘see’ them at the bottom.
<nav> tagOf Anna Fitzgerald’s
explanation I largely ignored the
section “HTML Dropdown Menu in Navbar”,
except that I tried out the <nav> HTML tag.
As I understand it, this tag is meant to mark parts of the code
that contain navigation information. But perhaps I totally
misunderstand.
Strangely, in my demos
01,
02,
04 and
05, where
the navigation links are correctly read by
Text Read Alone, this is no longer the case when I add tags
<nav> and </nav>
around the links block. Exactly the opposite of what I would
expect, and what I think would make sense.
Therefore I avoided using <nav>, and instead, in
the site-wide solution
I implemented
(here’s a
frozen copy of the CSS), I added a
role=navigation to a <div> tag.
Hope that helps.
I’m truly disappointed by the lack of support for accessibility for the visually impaired, seeing that already in the second half of the 1980s, there were practical solutions – albeit in a text-only non-graphical environment. That’s some 35 years ago, mind you.
I found that of this very page, the menus are NOT read by “Text Read Aloud”, although it works well in all the other pages of my site that I tested. “Text Read Aloud” stops after “all rights reserved”. No idea why.
It does work in Microsoft Edge, though, also with this page.
Copyright © 2023 R. Harmsen, all rights reserved.