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

Hi, Paul.

Two small accessibility points in the stock 3.7.2 desktop templates, in case they are useful for a future release.

1) The message box and topic title box have no label.
In main_post_form.html, the textarea (id="postText") has no <label>. The heading above it ("Message"/"Reply") looks like a label but isn't connected to the box.
In main_topics.html, the topic title input has no label and no id. Screen readers therefore announce both boxes as just "edit text", without saying what they are for. A <label for="..."> on each (and an id on the topic title input) would fix it.

2) Several h1 headings on one page.
The logo in main_header.html is an h1, and every headingTitle is an h1 as well. The new-topic page therefore has five h1s, including "Topic" and "Message", which are really field labels. It is not a validation error, but screen-reader users navigate by headings, and the usual practice is one h1 naming the page, with h2s for sections such as the reply form or "Recent discussions". The search and subscriptions pages have no heading at all.

Because headingTitle is styled by its class, changing these tags would not change the look.

Thanks for all your work on miniBB.
--marsbar

Thank you for suggestions, I'll take more closer look in the nearest time and will try to fix it all in the new version.

I know about multiple H1 tags and they are in the final polsihing queue.

As about screen readers — which one are you actually using? Could you recommend the best/common?

I've never tried them out (as it's a rare request), that's why for testing I perhaps would need to check how it all looks in practice.

Hi, Paul.

Thank you, that is great news.

I don't use a screen reader myself. Accessibility is part of my day job, so I'm used to checking websites against the W3C accessibility guidelines (WCAG). That's how I noticed these issues on our forum.

Which screen reader to test with:

• NVDA (Windows): free, and one of the two most used. Use it with Firefox or Chrome. This is the one I'd recommend.
• JAWS (Windows): the other most used, but expensive. Pages that work in NVDA usually work in JAWS too.
• VoiceOver: built into Mac and iPhone. It's the most used screen reader on phones.

(Source: WebAIM's survey of screen reader users, 2024.)

A quick test with NVDA:
Press H to jump from heading to heading. Most screen reader users move around a page this way. Each page should start with one h1 that names the page.
Press NVDA+F7 to see a list of all the headings and form fields on the page.
Press Tab to move into the message box. With a label, NVDA says "Message, edit". Without one, it only says "edit", so the user doesn't know what the box is for.

Alternatively, without installing anything:
Open the browser's developer tools: in Firefox, the Accessibility tab; in Chrome, the Accessibility pane.
Click the message box and look at its "Name". If it's empty, a screen reader has nothing to say.

Thanks again for all your help.

--marsbar

Hi again, Paul.

For your final polishing: I have now made and tested these changes on my miniBB set-up. I share with you the exact lines below, in case they save you time.

Two rules (WCAG 2.2):
— Each page has one h1 that names the page; sections use h2 (WCAG 1.3.1, 2.4.6).
— Each form field has a real label (WCAG 1.3.1, 3.3.2, 4.1.2). Without one, a screen reader says only "edit text".

All my changes keep the existing CSS classes, so nothing looks different. Most are one line.

1. main_post_form.html
Problem: the h1 (l_messageABC) is an extra h1 on every page that uses this form, and the message box has no label.
Stock:
My revised:
The arrow stays outside the label (otherwise its alt text joins the field name). The section heading moves to the page templates (2, 3, 4).
Small HTML error: after the toolbar's inner table, ]td is not closed before tr closes.

2. main_post_area.html – add before mainPostForm:
3. tools_edit_post.html – add before mainPostForm (the edit page has no other h1):
4. main_topics.html (new topic form)
— Form heading: h1 -> h2 (the forum name is the page h1).
— "Topic": h1 -> label:
— Topic title input: add id="topicTitle".
— Forum icon in the form heading: alt="{$forumName}" makes screen readers read the forum name twice. The icon is decorative, so alt="" is better.

5. tools_edit_topic_title.html
"Topic": h1 -> label. Input: add id="topicTitle".
6. main_header.html and front page
With one h1 in each page template, the logo in main_header.html should no longer be an h1.
main_forums.html has no heading, so the front page h1 is "Recent discussions" (a section).
— main_forums.html, first line:
— main_last_discussions.html: "Recent discussions" h1 -> h2.

7. search.html
No heading. Add under the breadcrumb:
Labels: wrap each caption in a label (same for searchType, where, forum, posterName), and add id="phrase" to the search box:
The six date dropdowns need hidden labels (we typed English text; stock would need language strings and a standard "visually hidden" CSS class):
Lower priority, not changed: the "[+] Search type" etc. links work as buttons but do not tell screen readers if the section is open or closed. A button with aria-expanded would fix this:
8. search_box.html
The box has no label (the Search button does not count). Ours:
9. main_subscriptions.html
No heading ("Watched topics" is bold text). Ours: close the b tag after the breadcrumb (h1 cannot be inside b), then the h1, then the [unread/total] count:
10. main_preview.html (not changed – needs PHP)
— No lang attribute on the html element (WCAG 3.1.1).
— New topic preview has the topic title as h1; reply preview has no heading. A heading on both would be better.

Not changed: some PHP files also output an h1 (e.g. bb_func_movepost.php) – admin pages, so I left them. I have not checked the Mobile add-on templates yet.

--marsbar

Thank you very much! This will definitely save my time.

I have revised part of issues for today, a few remarks below:

Actually, it looks different. <label> is inline element by default, and CSS' padding doesn't work with it. In /css/default.css there should be added:

Then the changes would look similarly as with H1s.

Good point — strange none of HTML validators I'm using showed that. Thanks!

2. That's not correct addition. In the main_post_area template, nothing should be added, because {$mainPostForm} could be different regarding if the topic is closed or not (and some other conditions). If you add the code like suggested, it will generate duplicated "Your Reply" heading amongst the code provided in main_post_form (p.1). In result, my version of the code for p.1 (main_post_form) is:

"id" works with <label>, and so does work the #newreply anchor in the URL field.

3. The same as above — if the code suggested is added, it will show duplicated content generated from main_post_form. However <label> addition from the main_post_form already takes care about the editing area. Then why would H1 header presented on this form? It's not a structured page. I'm not sure if a care should be taken on each of such forms, specifying H1 — they are A LOT, also present in the Admin panel and many other add-ons.

So, is there obligation for H1 on each and every page even if it's not a structured content?

4. I accept all changes mentioned here, with addition that <label> could include id="newtopic" as in p.1 above.

5. Accepted. As well, this form doesn't have H1 tags — I suppose it's still OK?

6.
Agree to this, and I'll change it to <span> in default package.

It should be enclosed in a table for being properly aligned:

That's, and above, fine for the old-style layout; however for the current (modern) style I won't change anything so far; Recent Messages will stay as the currently the only one heading present.

...

9. I'll change more codes in this template; but overall, the H1 will be present, agree to this.

10. No PHP changes are required for this. `<html lang="en">` is added to the top section of main_preview.html, and the <table> could be extended with a header like:

and $topicTitle becomes like for example:

-----

I already updated miniBB forums here with these changes, you can check them out.

As for the search forms, I'll work out them more deeper tomorrow or a bit later, this requires more "diving-in".

Thanks so far!

BTW codes like these could be fixed just changing H1 to SPAN, but keeping in mind such moderation pages won't have H1 titles at all.

Surely headings could be added, replicating what's present in the <title>, or containing phrases from the language pack — I'm just not sure how it all is important in terms of WCAG, 'cause administration pages are not content pages and are not supposed to be structured, 'cause there are not more or less important parts, all parts of such interfaces are common.

I think W3C doesn't require <h1> to be on every page, so admin pages don't need them.

I prefer to put <label></label> without any CSS styles too as it's probably not the best practice and it's better to style other elements if possible.

Why wouldn't it be the good practice? The tag allows applying CSS styles. Then why to not use it?

Also, not quite sure what other elements would be present to style if a label is already shown.

Thinking about the above written, I'm worrying about other forms... topic/reply/search forms are only the base for guest posting. Taking a look over miniBB, there are tens of another unlabeled forms — I'm just not ready for such work right now. For example, if we take the Profile form, it connects to many add-ons and conditional appearances of fields. It would be truly tough job to add labels just to this form.

Hi, Paul.

Thank you for looking at this so quickly. You are right that a label is inline, so it needs the extra CSS. And you are right about the preview: it didn't need PHP after all.

To answer your question: no, WCAG doesn't say every page must have an h1. It's good practice, but forms and admin pages without one are fine.

There is one thing to avoid: if text looks like a page title, it should stay a heading. If you change it to a span, a screen reader can't find it, and WCAG counts that as a failure (technique F2: https://www.w3.org/WAI/WCAG22/Techniques/failures/F2). So I'd leave the h1 on each admin page as it is.

I am looking forward to the new version!

Thanks again,
marsbar

Regarding this — may I know why did you add id='phraseBox' and not just id='phrase'?

I couldn't find the ids conflict so far.

Currently I've made some adjustments to the search_box template (available to check here on miniBB forums), and I'd prefer the label being visible, not hidden — just appearing with less "attention", so I've applied txtSm class to it.

I like a minimalist approach. I think that <label> doesn't need to have "for" and then the proceeding element doesn't need to have an id.

For example instead:

I prefer this which should work the same: