<![CDATA[SitePoint Forums - Accessibility & Usability]]> http://www.sitepoint.com/forums/ This forum deals with questions about helping users to access sites and use the web regardless of circumstances—be they blind, or unable to use a mouse, or just unfamiliar with a website and its contents. en Thu, 23 May 2013 21:43:01 GMT vBulletin 60 http://www.sitepoint.com/forums/images/sitepoint/misc/rss.png <![CDATA[SitePoint Forums - Accessibility & Usability]]> http://www.sitepoint.com/forums/ <![CDATA[Good or Bad: "Randomizing" Article Links]]> http://www.sitepoint.com/forums/showthread.php?1076320-Good-or-Bad-quot-Randomizing-quot-Article-Links&goto=newpost Tue, 21 May 2013 23:02:53 GMT I just added a "Section Landing Page" to my website, which lists all of the related "Sub-Sections" for the chosen "Section".

Each Sub-Section is displayed as a box with two parts.

On the left hand side is a "Featured Article" which displays a Heading, Thumbnail, and Summary.

On the right hand side is a list of 5 "Featured Article Links".

All of these ultimately lead the user to the actual Article itself.

So on to my question...

If every time someone visits this page, I change the order of the "Featured Article" and "Featured Article Links", would that be a good or bad thing?!

My motivation for "randomizing" the order is that it hopefully helps people to see different Article Headings, and thus maybe encourages people to read Articles they may not have seen or paid attention to their first visit.

If this idea seems legit, I may make it even more sophisticated, but adding "weighting" to each Article, so that *important* ones show up more often as the "Featured Article".

The only down-side I can see to this, is if a person hit the "Back" button on their browser, it might confuse them if the Article they just saw had moved... :blush:

What do you guys think?!

Sincerely,


Debbie ]]> DoubleDee http://www.sitepoint.com/forums/showthread.php?1076320-Good-or-Bad-quot-Randomizing-quot-Article-Links Links are not buttons! -- article by Karl Groves http://www.sitepoint.com/forums/showthread.php?1067624-Links-are-not-buttons!-article-by-Karl-Groves&goto=newpost Wed, 15 May 2013 07:47:34 GMT http://www.karlgroves.com/2013/05/14...ivs-and-spans/

The basics are this (with notes added by me):

- you get automatic semantics and accessibility using the right element for the job.
- if you don't (and use something like a div or span for a button) you need to manually add in all the accessibility and functionality yourself.

- links are clicked and activated with ENTER or single tap. They take you somewhere.

- buttons are clicked and activated with SPACEBAR or ENTER or often double-tap (this is why single taps on buttons are sometimes slow... browser is waiting to see if the tap is really a double tap. You can get around this by using touchEnd events instead of click events for your mobile pages). They usually Do Stuff rather than take you somewhere.

I'm guilty of using links to Do Stuff, quite regularly.

<a class="btn"></a>
If an anchor doesn't have an href attribute, it may not be focusable (I know addThis twitter buttons didn't work in any version of IE I tested in with keyboard, solely due to lack of href). AT doesn't see anything focusable or clickable there either. It does not exist as far as they're concerned.

<a href="#"></a>
If an anchor is empty and you're using a background image to show the clickable thing and its text, this can and will vanish when users have High-Contrast settings in their browser (Microsoft has a possible CSS option for reversed icons here and I only know of the High-Contrast issue on Windows but if images vanish anywhere else then this also can't be a complete solution).

The above link will also take users to the top of the page. Disturbing someone's focus even if visually nothing changes is a pain in the butt.


-------------------------MOAR NOTES---------------------------------
I've been using a non-existing hash for these: <a href="#void">link focus goes nowhere when clicked</a>. Still, I should be using a <button>.

If you're forced to deal with spans or divs as buttons, like trying to fix someone's jQuery plugin, you need to do *at least* all this:

<span role="button" tabindex="0">FAKE BUTTON</span>
Role of button gives it a role to browsers and AT. Tabindex makes it natively focusable without screwing with native tab order (don't set to a number larger than 1). Even so, now you can focus on it but can't activate it.

In your Javascript onclick method you need to add an onkeyup or onkeypress or whatever your favourite is and test for ENTER and SPACEBAR.
Here's a chunk I did for a jQuery plugin our company uses but by default only works with the mouse:
Code:
var resetbtn = item.find('.rateit-reset');
    if (stuff is true...) {
        resetbtn.click(function () {
            //does stuff onClick;
        });

    //is role=button, but not natively clickable
        resetbtn.keyup(function(e) {
            var code = e.which;
            if ((code === 13) || (code === 32)) {
                $(this).click();
            } 
        });
    }
]]> Stomme poes http://www.sitepoint.com/forums/showthread.php?1067624-Links-are-not-buttons!-article-by-Karl-Groves Modern Accessibility with Javascript and WAI-ARIA http://www.sitepoint.com/forums/showthread.php?1067543-Modern-Accessibility-with-Javascript-and-WAI-ARIA&goto=newpost Wed, 15 May 2013 07:20:20 GMT Paul J Adam has made a really simple resource for web developers concerning web accessibility and Javascript. It looks like something handy to bookmark if accessible Javascript is new to you, or you want to remember a technique. Lots of links and tests in there too. ... Paul J Adam has made a really simple resource for web developers concerning web accessibility and Javascript. It looks like something handy to bookmark if accessible Javascript is new to you, or you want to remember a technique. Lots of links and tests in there too.

http://pauljadam.com/moderna11y/

Check it out! ]]> Stomme poes http://www.sitepoint.com/forums/showthread.php?1067543-Modern-Accessibility-with-Javascript-and-WAI-ARIA JavaScript Popup: SEO, Accessability? http://www.sitepoint.com/forums/showthread.php?1060526-JavaScript-Popup-SEO-Accessability&goto=newpost Fri, 10 May 2013 20:11:14 GMT Hi everyone, I have a question about SEO and accessibility. Our programmer added this JavaScript popup to our website. It pops up on the first page that you go to and is as follows: ---Quote--- If you are planning to use the shopping basket during your current session, please consider... Hi everyone,
I have a question about SEO and accessibility.

Our programmer added this JavaScript popup to our website. It pops up on the first page that you go to and is as follows:

Quote:
If you are planning to use the shopping basket during your current session, please consider giving us an email address that we can use to recover your shopping basket items in case something goes wrong (which sometimes happens).

1. This is completely optional but strongly advised.
2. We will not use this email address for any other purpose than shopping basket recovery.
3. Leave the box blank if you do not wish to use this feature.
4. If you want, you can set this email address from the shopping basket page later.
5. Also, consider signing up for a free membership! That way your shopping basket items are always saved!

You shouldn't be seeing this message again anytime soon.

Please enter an email address below or click 'Cancel'
It contains a description of what the issue is with recovering shopping baskets that may otherwise be non-cached on the client's browser. (They walk away from their computer for a week and come back, expecting the shopping basket to still be there. We have a user login and a wishlist system too but they don't seem to understand that this is typically only a sign in and save feature for websites)

On the iPhone and iPad I can't read this JavaScript popup text at all because it is way too big for the screen. I also have questions about whether this is hurting SEO or not, it seems to definitely be a downgrade for accessibility. It will go away if you click Cancel but I can also just see it as a bad experience for a customer's first impression of the website.

Any thoughts and opinions on it?
Thanks, ]]> revlimiter http://www.sitepoint.com/forums/showthread.php?1060526-JavaScript-Popup-SEO-Accessability Web Trust Seals http://www.sitepoint.com/forums/showthread.php?1058510-Web-Trust-Seals&goto=newpost Thu, 09 May 2013 18:43:57 GMT I could not think of any other forum section that this would fit into, so here goes nothing. I am interested in building web trust to my website. I found the following: * Web of Trust (http://www.mywot.com/en/trustseal/comparison) * Semantic Site Safe... I could not think of any other forum section that this would fit into, so here goes nothing.

I am interested in building web trust to my website.

I found the following:


I am interested in exploring more web trust seals. Understandably it's possible to go OTT, and I easily overspend in making myself look safe, that being said if you're paying for advertising you would want to ensure that all your potential customers trust you. ]]> Sega http://www.sitepoint.com/forums/showthread.php?1058510-Web-Trust-Seals Looking for a Section 508 compliant HTML5/javascript Framework (UI Controls) http://www.sitepoint.com/forums/showthread.php?1056546-Looking-for-a-Section-508-compliant-HTML5-javascript-Framework-(UI-Controls)&goto=newpost Tue, 07 May 2013 17:49:48 GMT Hello, I was taking a look at Kendo UI, but it appears to not be fully Section 508 compliant. Does anybody know of any UI frameworks that are? Thanks! Hello,
I was taking a look at Kendo UI, but it appears to not be fully Section 508 compliant. Does anybody know of any UI frameworks that are?

Thanks! ]]> GOLGO-13 http://www.sitepoint.com/forums/showthread.php?1056546-Looking-for-a-Section-508-compliant-HTML5-javascript-Framework-(UI-Controls) <![CDATA[Results from WebAIM's low-vision user survey]]> http://www.sitepoint.com/forums/showthread.php?1055127-Results-from-WebAIM-s-low-vision-user-survey&goto=newpost Mon, 06 May 2013 09:04:35 GMT http://webaim.org/projects/lowvisionsurvey/

Following up their successful screen reader user surveys, here's one targetting low-vision users (some of whom also use screen readers). Unlike the screen reader surveys with around 1000 respondents, this survey ended up with just 216 valid responses. Hopefully the next low-vision survey will have more! If you know someone who regularly uses the web and has low vision, ask them if they'd be interested in the next low-vision survey, whenever WebAIM does it.

While a majority of respondents were nearing middle-age or older, they reported their vision impairment isn't a result of age, but something else. A little over half wear some kind of vision correction such as glasses. A majority were regular and experienced internetters. Many used a combination of AT such as a screen reader with a magnifier, as well as the built-in browser controls for things like text enlargement or contrast settings. Unsurprisingly, a large majority of users found default web text too small, and found good colour contrast to be *very* important.

Interesting findings:

- Younger people tended to use mobiles more. This likely reflects a general device trend though.
- Probably reflecting the general internetting population, Windows and IE were the most popular combination. What the survey mentions as interesting is that iOS is the second-most popular OS.
- Like most everyone else, they had Javascript enabled by default.
What I think this means to web developers is, when you're using Javascript (ajaxy stuff especially), be aware that things like growlers and flashes/alerts may get wholly missed by users of screen magnifiers, if the alert/change is not near where they initiated the action. Screen magnifiers show a small portion of the page. So keep in mind you may want to not only use aria role="alert" on updated or new items somewhere on the page (can be announced by screen readers without moving the focus), but also some visual feedback cue near where the user initiated the action (like a "buy" button changing how it looks).
- iThings, Android and Nokia were the three most-used mobile platforms.
- Skip links were found to be of course more useful to keyboard users, and to beginners, but with the high prevalence of iOS users where both touch is the main input type and webkit's in-page-link bug is present (very recently fixed), I wonder if more people would otherwise be using skip links. I mean, you wouldn't use them with webkit browsers as they don't do anything for you but move visual focus down, and don't save you from having to tab your way down to where you want your focus to be. iOS also has some kind of web rotor thing for navigation, though I don't know how popular it is. Would be an interesting question to add to the next survey.
- Zoom Text (a combo screen reader and screen magnifier), JAWS and VoiceOver were the most popular "screen readers" (in quotes because of Zoom Text).
- A great deal of users used keyboard, but generally a mixed bag, as was whether text-enlarging widgets (like the a, A, A things) were useful. The majority of respondents stated they like these widgets and would like more. WebAIM cautions web authors (us developers) about this though.
Quote:
Originally Posted by webAIM
Opinions of in-page text resizing widgets are very mixed. Respondents who always or often use a keyboard found these widgets much less useful than non-keyboard users. Interestingly, those who use browser text sizing options were twice as likely to find in-page text resizing widgets very useful than those who do not use these browser settings. Those with beginning internet proficiency were much more likely to find them useful than those with advanced internet proficiency.
(text bolded by me)
I wonder if this has something to do with sites usually using cookies with these widgets, meaning users' choices get remembered. Browsers may or may not remember enlargement settings such as CTRL++ on a per-domain basis, especially if you have various privacy settings on. For me, Firefox (with text-enlarge only) remembered domains, while right now with my current settings, Opera does not between sessions (only during sessions).
It may also be that if developers bothered adding text-enlarging widgets, which work different from the "zoom" offered by browsers, that they probably also bothered testing what these settings looked like, and made sure their page layouts didn't break. I still encounter layouts breaking or making long scroll bars with both zoom and text-enlarge, which I use on almost every site I visit.

The top 3 most problematic things (of 11) users found on websites?
1. Complex page layouts
2. Content that becomes unreadable when enlarged
3. Poor contrast

Note CAPTCHA is #4. ]]> Stomme poes http://www.sitepoint.com/forums/showthread.php?1055127-Results-from-WebAIM-s-low-vision-user-survey <![CDATA[Are these URL's too long??]]> http://www.sitepoint.com/forums/showthread.php?1049891-Are-these-URL-s-too-long&goto=newpost Tue, 30 Apr 2013 14:45:02 GMT Are the following URL's too long or complex from a Usability standpoint...
Code:
www.mysite.com/finance/accounting/why-you-should-hire-a-cpa

www.mysite.com/legal/s-corp/benefits-of-incorporating-your-small-business

www.mysite.com/legal/online/make-sure-you-are-charging-sales-tax

www.mysite.com/marketing/going-live/how-to-tell-the-world-about-your-new-business

They follow this simple pattern...

Category > Sub-Category > Article


My website is very complex from a Content-perspective, but in my opinion, the above scheme has helped me whittle things down to something very manageable.

Unfortunately, I have one person who is protesting, and says that my URL's are way to long?! :-/

(Apparently he hasn't been to Amazon.com lately...) :lol:

What do you think?

Sincerely,


Debbie ]]> DoubleDee http://www.sitepoint.com/forums/showthread.php?1049891-Are-these-URL-s-too-long Best practices for 4 level navigation http://www.sitepoint.com/forums/showthread.php?1049824-Best-practices-for-4-level-navigation&goto=newpost Tue, 30 Apr 2013 11:48:45 GMT Hi there,

What are the best practices for a four level navigation?

I've been looking into a few options but was just wondering what everyone's thoughts are.

Here's what I've been looking at

  1. Mega menu
  2. LHS navigation for all levels with expand collapse
  3. LHS navigation for level 1 & 2 then tabs for level 3 & 4
  4. Tabs for level 1 & 2 then LHS navigation for level 3 & 4


Its a revamp of an admin console for setting up one of our products and is currently using a 3 level navigation but after dealing with the support issues I'd like to split level 3 into sections.

Here's an example of the current navigation

toolbar
tabs
sub tabs

Actually just had a thought, maybe i could have a drop down on the existing toolbar items to show the level 2 nav, then from there have the tabs (level 3) then introduce level 4 as the sub tabs... interesting.... will go investigate

Thanks
Gillian ]]> gillian http://www.sitepoint.com/forums/showthread.php?1049824-Best-practices-for-4-level-navigation