Update: The approved solution seems to be leave them in there but have a user option to enable/disable. The default will be disabled.

sounds good.

I'll have a think about the extension - I'm not sure it would be possible but it'll depend on the hooks available. If they can be turned on/off then that suggests a possible hook implementation though.

Update: The approved solution seems to be leave them in there but have a user option to enable/disable. The default will be disabled.

Update2: Done but not yet committed to SVN.

I have to say though congrats to all involved -  didn't find any major issues (I'm not an expert). Others may find issues I haven't.

same comment about links (underline when active etc)

Skip link - 'skip to forum content' this is fine on the public side, but is the wording OK for the admin pages?

<div class="main-head">
        <h1><span>{ Information }</span></h1>
    </div>

appears *after* the navigation menu - meaning you have to got through those links before you find out what page you are on (well if the page title is ignored). I realise it may not be possible to move this, so just a comment about it.

Settings - Features
1. General features (go to censoring to setup censored words list)

surely the bracketed text would be better served if it was next to the censor words selection?

[edit : snip posted elsewhere]

Extensions (I hope I didn't miss this elsewhere)

When installing a lot of the text appears within the <form> even though there is no actual need for it. It might be better to have the text display before the form.

On a separate note, that extension section is going to get very big very fast for some of us - could the details shown be reduced to bare minimum, with a 'more details' link?

damn blast and ******:
accesskey="s" title="Accesskey: s" on the send an email form - is that all over the place? It would be preferable if there were either NO accesskeys set, or they were settable by the user. I can cite references on this subject(Wats.ca), and provide you with a few links to pre written accesskey scripts (my coding is not the best in the world, but I do have one...)
quick grep finds occurances in:
edit.php(344)
edit.php(345)
misc.php(256)
misc.php(398)
post.php(539)
post.php(540)
search.php(1234)
userlist.php(192)
viewtopic.php(578)
viewtopic.php(579)
lang\English\common.php(25)
lang\English\common.php(27)

With the plugin and extendable possibilities opening up, erring on the side of caution and adding them may be best

Is there a reason for the left-right order in #pun-visit? That is, visit links on right and login info on left?

I consider the visit links more important than the login info, therefore I think they would be better aligned to the left. I know I can change this with a float, but I've never quite understood why is it so. I think this is a good chance to know.

Personal preference stemming from wanting to avoid putting links immediatelly under the main menu links which I think detracts from the importance of the menu bar. In fact, my preference is for adding "New posts" to the main menu but I keep getting overruled

Rich: not an accessibility issue really and its the index page. As for the table captions (I read that article several time already), I did have them but they really just duplicated the h2 headers which appear on top of each table. I didn't think they actually added anything useful particularly as a summary is provided. Plus they would have to be invisible and one browser was refusing to shift them even when absolutely positioned into the heart of the Gobi desert. I will think about it again though because I think the stubborn browser was either FF1.5 or Opera 8.5 neither of which are current.

I consider the visit links more important than the login info, therefore I think they would be better aligned to the left. I know I can change this with a float, but I've never quite understood why is it so. I think this is a good chance to know.

Tables should have <caption> as well.

Accessible Data Tables which is hefty reading but does fetaure a bit about scope against id and headers.

last post link, works for me. well thought of!

BTW. If you are wondering why I didn't just go for a visible skip link, it was pure pragmatism. I figured a large percentage of installers would just see a visible skip link as pointless and ugly and promptly delete it. This way they are more likely to leave it alone. For people who prefer it visible they can just edit a couple of lines of css.

EDIT: Last post link: Since the same user cannot make two posts at the same time, if the "by username" part was included in the link that would automatically eliminate the possibility of having identical link text going to different locations.

Rich. First of all thanks for taking the time.

no problem.

I should have realised! It doesn't worry me as such, and certainly doesn't affect accessibility anway.

arggh my bad I missed the fact the label went around it all.

It is a simple table, and I'd have to ask around for the definitive on it. Overkill, well adding accessibility specific markup on tables is always seen that way anyway - scope ought to be enough I'm just not sure it is

Hidden text isn't the answer - my other half has occasionally had to keyboard navigate, and utilise Dragon naturally speaking which is where the issue of unique visible link text is perhaps more necessary.

One to ponder over in the coming months.

Thanks.

I think it would be better, lets face it it made me wonder why, so I'm sure others will as well.

great minds...

As with all I post it can only be suggestions, some will be good, some will be bad.

As regards divitis. The board description can take html. If I were to use a <p> I guarantee somebody would put a <div> inside it. If I were to use a <p> in the default title then I guarantee somebody would add a title with no markup so we are back to juse a single div. You ar probably right about the title part though.

Quick post form. An oversight on my part. Should be the same as the main post form.

Tables. I will do some research regarding id's. I'm sure when I showed somebody a versio with id's they said it was overkill for a simple table but I will look into it further.

Last post link. I can't come up with a solution either. Just putting in an id or something as hidden text is just a hack to satsify the checkpoints and would actually make things worse.

Links. I will look into it.

Profile avatar. Its required because it needs a value before submitting the form otherwise you are submitting a form which does nothing. My favoured solution would be to remove the required indicator and then change the error text which appears if you submit the form to "You must select a file to upload before submitting this form". That traps the mistake without misleading people. I could also add help text under the field which is part of the label which says the same thing.

search results. That was actually on my list.

EDIT: Rich, just checked the quickpost form and the required text is in the label, same markup as the main post forms.