miniBB 3.7.2 — Accessibility issue: posting form fields have no labels, and pages have several h1 headings

My late night thoughts to this... while the world still would need human posts, and minibb handles them easily, the Reader interface could be so easy nowadays, not even compared to all this outdated low-quality indexed NVDA-stuff-like.

I'd imagine the markup would still have major <label> tags, but not oriented to a specific Reader model.

Let's say, a blind person gives a voice command to the website or forum: explain me where I am? — And it takes <title> and <description> for explanation. No <h1> tags are ever involved.

Then s/he gives a command: list all current topics I could read participate in. And just the whole list of Recent topics is read.

It's enough to say "Stop! Read it!" Or just go back to the list, or continue the pagination list.

Then, if from the forums menu there is sort of Form available, the Reader should explain this form, using the present aria-tags, <label>s or whatever. The instruction listing all fields, just should be present on this form in a way it could be filled in and submitted by a blind user. Distinction to the current Reader is that the User could give questions about any form's field, and receive immediate answers.

Right now, I see that the combination of these tags, and the Screen reader programs are coming like from a stone age... I definitely wouldn't like to develop miniBB being stuck in a stone age.

It's being mini, it may called old-fashioned, but it definitely works on a huge mass of devices I'm experiencing it.

The question is, wouldn't be even possible to code the Website Explainer like I described? Using AI-tools? I couldn't believe it's impossible.

G'day, Paul.

Thanks for considering all these suggestions. Happy to leave the rest to your To-do list.

Icons: if they also have title attributes, it is worth removing or emptying those too, as some screen readers read them.

Period dropdowns: here is an approach that does not need hidden text, so it will not affect search engines. Keep the fieldset with its visible legend, and add an aria-label directly to each select:

NVDA should then read something like "Period, grouping, From day, combo box, 1". The same approach works for all the selects. You already have Day/Month/Year in the language pack, so only "From" and "To" need adding.

Expand buttons: one last thought and I will leave the topic alone. If the button's only text is "+", NVDA announces "plus, button, collapsed" without saying what it expands. A short aria-label such as "Formatting" makes it quieter and more useful, which fits the "mini" idea. Your decision, of course. :)

The AI explainer: I think you are right about the future, and some of this technology already exists. Screen readers now have AI add-ons that describe images and screens. AI browser assistants can also read web pages and fill in forms by voice. However, these tools still rely on the same underlying HTML: titles, headings, labels and buttons. Clean, semantic HTML is therefore the foundation for these tools, not an alternative to them. It also helps search engines, which use the same structure. In short, the "mini" approach of simple, well-structured HTML is exactly what makes miniBB ready for whatever readers come next, AI or otherwise.

Cheers,
marsbar

Previously, I already tried it out, and this approach would work for an English reader, but for any other languages, it's not that universal — specifically for those having right-to-left text positioning. Right now, to the language pack I've just added:

but for your case, there must be added:

— there is no proper approach for other languages just to combine $l_from / $l_to vars with a single definitions of Day/Month/Year within dropdown labels, it will be heard then even less correct than now.

Now it reads when moving by Tabs: Period from grouping — Day combo box 18 collapsed, Month combo box Feb collapsed ... Period to grouping ... the same for Day/Month, their values etc.

It appears aria-label doesn't work for the <span> tags, where +/- signs reside in. But on my side, NVDA reads button values, no aria-label is required. It reads exactly like "Formatting button collapsed", and if the Enter is pressed, it reads now "Expanded". Then if I go through this set again, it reads properly the button value/title and its status, collapsed or expanded.

I agree there should be some strict markup base for these tools. I'm just about the current state of things, which allows to prepare some very basic, reader-like documents, but if we are about the forum, it's more complicated structure. Now I see that if we try to embed reader-required HTML into the current markup of the forum, it doesn't ideally work, and just adds extra bits of codes which would not work certainly the same on all devices.

There could be form of alternative markup, for example JSON-LD or XML-based, similarly like Google did with their Structured Data addition. It wouldn't just being embedded into the current templates layout, but stand out like a separate file being included with a special meta tag — similarly like now JavaScript or CSS codes could be referenced. And then, this file could have more strict and organized structure, clean from visual elements, and represending just structured texts and form labels the reader should take into attention. And it could be way more different from the structure which is accessed by a regular user.

Just my thoughts, and for now, we just should rely on the standards already written...

Hi, Paul.

Good points!

Period dropdowns: you are right. Separate full strings are the proper way to handle translations, and joining words does not work in many languages. "Period from, grouping, Day, combo box" gives the context perfectly well, so I would leave it as it is.

Buttons: great. If NVDA reads "Formatting, button, collapsed", that is exactly right. No aria-label needed.

Separate markup for readers: an interesting idea, and something similar was tried years ago with separate "text-only" versions of websites. They tended to fall out of date with the main site and were eventually abandoned. In a way, browsers already do what you describe: from the HTML they build an "accessibility tree", which is a clean structure of headings, labels, buttons and their states, free of the visual layout. That is what screen readers (and AI tools) actually read. So well-written HTML effectively produces that separate structured version automatically. I agree, sticking to the standards is the way to go.

Thanks for all the work on this! It has been a really useful exchange, and I shall look forward to the new release.

--marsbar