You are not logged in. Please login or register.
PunBB Forums → PunBB 1.3 troubleshooting → Accessibility testing
If there are any screenreader users, keyboard navigators or in fact anybody interested in improving accessibility please post test results and comments here. I don't expect must response at this stage there being no public test board but you never know.
I'll install locally and see what I can do - especially as I did offer!
Some of this is not directly related to accessibility but found during testing - if it isn't suitable here let me know and I'll repost other bits elsewhere.
This is just a quick front end test, I'll work on the back end another time.
All tested with the default theme.
divitis, some of these should be <p> not <div> eg.
<div id="pun-title">
<div><strong>beta beta</strong></div>
</div>
<div id="pun-desc">
<div>punbb access</div>
</div>the inner div's could easily be a <p>
I realise that as many hooks have to be put in as possible, but if the number of div's can be cut down it may help. (yes I know it is probably themeable)
The skip link, even works in IE7 (haven't tried in earlier versions)
In table markup I see use of: scope="col" this isn't as good as utilising headers and ids, more difficult to code, but may be more suitable.
Default last post link text - eg.Today 10:59:23 it doesn't really describe what it is linking to (but you can easily argue 'it should be bloddy obvious on a forum') however there may be some times when the link text is not unique, and therefore you might get 2 links pointing to different places but with the same dats and time - which would make this unsuitable. Sorry I haven't got a suggestion at this time to fix it.
Suggestion re links - if underlined remove underline on hover(and active etc), if not underlined, add underline on hover(and active etc). This does happen in some places, but not all. eg breadcrumb
Quick post form,
<em class="req-text">(Required)</em> if that text isn't in the <label> then screenreaders who have gone into forms mode won't be able to 'hear' it. However I do notice the workaround on post.php, but it wasn't implemented here.
Profile section : avatar
sounds like a silly question but why is it 'required' when surely it is optional?
search result - suggestion, add an id(#searchresults) and send the user straight to the results, rather than forcing someone to tab through (or even scroll down).
If anything needs explaining further or expanding on, feel free to ask and I'll do my best to answer them.
Only thing I'll comment on here:
In the avatar form, the avatar is ofcourse required. But you're not required to use the form.
I'd thought of that, the same could be said of the signature form which doesn't have required on it.
Rich. First of all thanks for taking the time.
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.
Rich. First of all thanks for taking the time.
no problem.
As regards divitis.
I should have realised! It doesn't worry me as such, and certainly doesn't affect accessibility anway.
Quick post form.
arggh my bad I missed the fact the label went around it all.
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.
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 
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.
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.
Links. I will look into it.
Thanks.
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.
I think it would be better, lets face it it made me wonder why, so I'm sure others will as well.
search results. That was actually on my list.
great minds...
As with all I post it can only be suggestions, some will be good, some will be bad.
One solution to the last post issue might be the same solution as the skip link i.e. information in a span nested in the link which appears when you hover or tab. The screenreaders should have no problem with that. The trouble with visible link text is the amount of space available.
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.
hidden skip link works for me, and is ideal for this situation.
last post link, works for me. well thought of!
Ok found another thing while looking for a decent accessible table article.
Tables should have <caption> as well.
Accessible Data Tables which is hefty reading but does fetaure a bit about scope against id and headers.
Screen reader support for scope however was patchy.
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. 
you've lost me on that one - which page is that on? (if it is this one I apologise in advance)
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.
LOL Paul re the captions. We've had problems with IE and all things so I wouldn't be surprised if it wasn't IE6. If the table immediately follows a <h2> then replicating the info in the caption would be pointless. But if there is anything in between, or even the possibility of anything in between then I think they would become more relevant.
With the plugin and extendable possibilities opening up, erring on the side of caution and adding them may be best
Onto the admin
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)
and that is about it for an initial check - I'll need to do some further testing once I have access to a site with 'data' - I was testing on the initial install.
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.
For those who might be interested. The problem with table captions is an Opera problem. Opera 8 would not hide the caption completely using the off-left technique. Opera 9 will hide it but due to a bug, in certain circumstances the columns collapse to equal widths. The solution is to put a span inside the caption and manipulate that. Basically its the same kind of issues that crop up with fieldset legends.
Paul - what news on the accesskeys?
None. I will commence nagging. I'm now wondering if the class you developed with Gez Lemon for user controlled accesskey assignments could be used as the basis of an extension.
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.
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.
PunBB Forums → PunBB 1.3 troubleshooting → Accessibility testing
Powered by PunBB, supported by Informer Technologies, Inc.