Title
ALT tags to describe icons for blind users

Short, concise description of the idea
Our userpic icons do not presently have the ability have an ALT tag which can describe them to low-vision or blind users.

Full description of the idea
I have a blind friend who reads my journal and numerous other journals. For her to "see" our userpic icons, we presently have to type out a description in the body of our post, which is tiresome, repetitive, and clutters things up for sighted friends.

An extra blank should be added to the userpic icon upload page. Right now, we have the keyword blank, and the comment blank. There should be a third blank, "ALT", in which we could type brief descriptions. Then, a blind user could "look" at the userpic icon and "see" what it says. The ALT tag attribute blank should be optional, just like the comment blank is (and the keyword blank is not).

• 1. Bring LiveJournal into better compliance with the Americans with Disabilities Act of 1990.
• 2. Make the site more friendly and useful to disabled users and their families and friends.
• 3. Make the LiveJournal experience more complete for vision-impaired people; mitigate the present appearance of being a disability-unfriendly site.

• 1. Programmer time to change the icon-upload interface.
• 2. Probably only those users with blind / low-vision friends or who are blind / low-vision themselves will bother to put ALT tag descriptions on their userpic icons, so the additional burden on the servers should be minimal.
• 3. This is a very easy fix and the right thing to do morally, legally, and in terms of public relations. Nonetheless, some people might complain about being "too nice." They should be ignored or smacked down, but that will make them grumpy and whiny.
• 4. I don't know if Gallery images permit an ALT tag because I don't use my Gallery. However, even if they do not, adding ALT functionality to the Galleries, which few people use, seems a lot less important than adding ALT functionality to the userpic icons, which appear on almost every post.

kightp

Title
ad suggestion

Short, concise description of the idea
placement & type of ad (text/image) options for plus users.

Full description of the idea
Rotating ad links. Instead of images use text links as your ad. It's just as effective and those who can't see the ad have a disadvantage if it's a image. Also placement should be a option for all ads. Not just the top & bottom, left & right to chose where the location should be Some prefer both ads on the top, some the bottom, some prefer the left and some prefer the right.

• those who use screen readers can benifit the image ad being a link ad.
• Link ads can be rotated either when page refreshes or after a few seconds.
• Customize wheather link ads should rotate via a selected time, or when the page refreshes.
• Customaization for where both ads should be. Users can chose both top/bottom, just the top, just the bottom, left/right, just the left, just the right.
• If linked, no more advertisement link above the imaged ad.
• Saves room on the journal. If you have a screen magnifyer it overwhelms most of the screen.
• If approved, this option should be open to all users who use the plus account type.

• Screen reader users can't see the images and it can pose problems for navigation.
• Screen magnifyer users have a problem seeing thext as the imaged ad is in front of it.
  

Title
button positions

Short, concise description of the idea
I am hoping the 'flag this' button can be moved away from the other buttons.

Full description of the idea
Hi, I have a neurological issue that makes my mouse movements a bit jerky and make me click things I do not intend to. I have already clicked the 'flag' button by accident. If it is further away from the 'manage friends' button I think it would make false clicking less likely, at least from me.

• 1. Fewer false clicks on the 'flag this' button (at least from me).
  2. I will have to back out of the 'flag' gui fewer times. :)
• 
  

• 1. It requires work on someone's part and as I do not code, I am unsure how much work that is.
• 2. 500 people will complain about how button movement is against their civil rights and threaten to get myspace pages instead (this might be a benefit really).

Title
Add login form to "Forbidden" (403) page, when user not already authenticated

Short, concise description of the idea
See title. 403 page should prompt unauthenticated users to log in, instead of the user having to find another page log in.

Full description of the idea
Regular scenario in my life: I make flocked post. I go away. Someone comments to my flocked post. I get comment email. I receive email and want to reply. I click on the reply-to link in the email and, Whups! I'm not logged in. So then I have to, you know, find another page to log in. Huh? Like every other website on earth with personalization, prompt the user to log in!

• 1) Convenience to users.
• 2) Makes LJ look that much more professional.

• I presume it's no big deal for LJ's 403 page, which seems to be already custom, to differentiate between unauthenticated browsers (not logged in) and authenticated but unauthortized users (logged in, but not on flock flist). So as far as I know, this is, like, a half-hour's work with no ostensible drawbacks in its most elaborate form.

• "Forbidden
• You don't have access to that post with your current login status.
• Log in to LiveJournal
  Username: ______________
  Password: ______________
  Secure | Standard
  (Forgot password?)"
• etc.
• Or if that's too hard:
• "Forbidden
• You don't have permission to access to that page with your current login status.
• Log in to LiveJournal"

Title
Improve the Previous/Next Entry Navigation In Entry View

Short, concise description of the idea
Have the previous/next entry buttons on an entry provide more information about the entries they will take you to and have them only take you to entries you can access.

Full description of the idea
Currently, the Previous/Next entry buttons seen on entry view in a journal provide very basic functionality: they take you to the appropriate entry, regardless of security setting for that entry. If you can't read the entry, you get an error message. On journals where there are a large number of friends-only or private entries, this is not useful to anyone other than the journal owner. The previous/next entry buttons should only navigate to the entries readable by the person viewing the journal. As a bonus, a hover context menu coudl be added indicating the title, date, and tags applied to the entry they will take you to.

• No more annoying "hey, you can't read this messages" with no way to get around them.
• Easily find entries you're looking for, with all comments displayed and no lj-cuts.
  

• May cause pages to load slower for browsers that don't properly support the hover context menus.
• Increased use of processor time to verify which entries can be read by the person browsing the journal.

• I think I covered that.

Title
Making LJ easier to read for dyslexics

Short, concise description of the idea
Pages that are currently displayed as black text on a white background could be changed to have a pale coloured background and text that is not black.

Full description of the idea
Black text on white is not easy for dyslexics to read. You find black text on a white background all over LJ, but most notably if you click on the LJ cut of an unpaid account journal. As far as I'm aware, this is not user controlled and there is no other option as to how these pages are viewed.

(I used to get round this problem by highlighting text with the mouse as I was reading, but since the implimentation of the new style, text doesn't seem to be highlighting in the same way, although that could just be my computer - either way, pages displaying as something other than black text on a white background would be an improvement)

• Live journal is easier to read for dyslexic users

• Looks less clean and simple
• People might not like colours chosen

• Helpfull colour schemes include pale blue with dark blue text, or a light yellow, creamy background with dark text.

Title
change to navigation bar?

Short, concise description of the idea
Your reorganization of the links at the top of the page makes it difficult for some individuals to access the "Update Journal" link. I elaborate and offer a suggestion for reorganization below.

Full description of the idea
Putting "My LJ" over on the far left makes it necessary to draw a little backwards-seven-with-a-dip in the air to get to the "Update Journal" option, which is annoying and kind of difficult if you have a laptop with one of those touch panels instead of a mouse, or if you have small-motor problems. Before, you could go straight up and directly to the "Update Journal" option now you have this in the way every time.

• More often than not, the average user is going to update their journal whenever they log on. They might not use the "My LJ" option nearly as often.
• Complicating the motion necessary to access the "Update Journal" page is significant for people with touch panels or roller ball mice, or people with small motor problems. The most used feature should be the most accessible and easiest to get to.

• If you move the "My LJ" link to another place, it's not as obvious that you've made this big improvement, especially since people usually go right for the upper left without looking at the rest of the page.

• They have psychologists who study things like this, where to place things to best catch the consumer's eye; in my opinion, the next best place would be either one space over to the right, so you see it when you're clicking on "Update Journal", or all the way over to the right, in a sort of place of honor.

Title
Reduce dependency on JavaScript

Short, concise description of the idea
When an old page is replaced with a new version that uses fancy JavaScript, a link should be provided to the old version.

Full description of the idea
LJ is introducing a lot of new features which need JavaScript (the Xcolibur sitescheme, QuickReply commenting, AJAX commenting, the new update page, the new S2 editor, the proposed new portal page...). This is all very well, but not all these features degrade gracefully for people who don't have JavaScript or don't have modern browsers.

Obviously the developers can't be expected to make every page compatible with every weird or ancient browser out there. Hence I'm proposing that JavaScript heavy pages provide links to non-JavaScript pages, a bit like Gmail's "HTML only" version.

So for example, update.bml could include a link to /old/update.bml, the new S2 editor could provide a link to the old S2 editor (which was ugly, but a lot more widely usable than the new one). Ideally, it should be possible to set a site-wide preference in a cookie that you don't want to see JavaScript on site-based pages, but that would be more work and perhaps not justified.

• More features of the site would be useable for everyone. I'm talking about some pretty core features, like the ability to post entries or reply to comments, not just frivolous add-ons, here.
• Not everybody has the ability to upgrade to a newer browser or change their JavaScript settings.
• The range of ways people can access the web is growing all the time. As well as catering for older computers, LJ should consider new technologies like WAP and who knows what might be invented in the next few years.
• People who find they can't display a page properly are very likely to just give up and leave the site. Having lots of JavaScript which is broken for many users is ultimately going to cost business.
• Better accessibility. The more of the site is available in as simple a format as possible, the more easily people with various disabilities are going to be able to use it.
• The old, easily useable versions of pages already exist, so this would require little or no new coding.
• Less developer effort spent on making JavaScript work cross-browser. If users have the option to use the old version, it will be less of a problem when unforseen bugs show up. For example, there was a huge kerfuffle over QuickReply until eventually an option was provided to turn it off; had that been available from the start, that would have been avoided. Likewise, there was a lot of stress and emergency patching needed to fix the update page so that it was even vaguely workable for a large number of users.
• Lots of people dislike change, so having old pages available would quell some of the whining when a new feature is introduced.
• Even though the proportion of users who can't deal with modern JavaScript may be small, in absolute numbers it's a lot of disgruntled users because the userbase is so huge.

• JavaScript looks cool and modern.
• Some of the old versions of pages are pretty sketchy.
• Some new features might just not be possible without JavaScript.
• It's generally good to retire obsolete code rather than keeping it running in parallel with new code.
• It might be argued that it isn't worth any effort at all, even the most trivial, to support minority browsers.

• If an old HTML / BML page is replaced with a new JavaScript page, the new JavaScript page should contain a link to "HTML only version", and the old version should be kept available on the site.
• If a new feature is introduced that relies on JavaScript, the option should always be added to disable it, at least in the console (qv QuickReply comments).
• There should continue to be an option to display comment pages in the sitescheme (as there is now), even if that ceases to be the default. [link]

Title
Include alternative text for the cute little "talk" icons

Short, concise description of the idea
Add some kind of textual alternative for the little icons that can optionally be selected when posting a comment.

Full description of the idea
It seems common in this very suggestions community, and presumably in other places too, to use the little thumbup and thumbdown icons alongside a completely empty entry to indicate agreement or disagreement with a proposal. However, these little icons have no alternative text, meaning that the comment has absolutely no useful content to any user who for some reason cannot see images.

Some alternative text should be added to these images so that these users are able to discern the purpose of the comment.

• Makes the comment icons more accessible
• In line with web best practices
• Current image elements, lacking an alt attribute altogether, are invalid.

• What should the text say? "Thumbs up" might seem the obvious choice, but that's a visual gesture that might not hold any meaning for someone who has never seen it. On the other hand, we must be careful not to load the icons with too much meaning, as many users won't see the alternative text and thus not see what they're saying to a user that does not see images.
• Where should the text come from? Ideally it should be translatable, as not all users can read English well. However, shouldn't an English comment always be displayed with an English caption regardless of the viewer's language? How do we know what language to use in that case?

• Change the codings! lolz.

Title
A Global 'style=mine' Setting

Short, concise description of the idea
Have a 'view all LJ in your journal style' option.

Full description of the idea
In a similar, but more encompassing manner, to the existing 'View comment pages in your journal style?' I would like to see a 'View all LJ in your journal style' option. This would simply tag ?style=mine on to any page, which can already be done manually.

• I can already make LJ look how I want for everything I normally go to. However, if I start browsing around a bit more it reverts to showing me stuff in different styles. Seeing as this can be overridden by manualling adding '?style=mine' I think it would be nice to be able to set this as the default.
• This might be especially relevant for anybody who has set up a specific scheme for a reason, such as to work with a screen reader, or to aid with colourblindness.

• Currently I can have it so that viewing comments on my friends pages is done in my style. However, when I make a response it then jumps back to the comment thread but displayed in their style now. This would seem slightly contrary to the option as stated.

• A checkbox option on the editinfo.bml page - 'View all journals in your stlye?'.
• When this is turned on, all links to journals should have '?style=mine' tagged on the end.
• When this is turned on, all links to specific comments/threads should have '&style=mine' tagged on the end.
• When this is turned on, the results displayed when adding a comment to any journal should be returned as if 'style=mine' is present. (NOTE: this should be done anyway based on the currently existing setting for viewing friends comments).

Title
Voice Recognition Software

Short, concise description of the idea
I use Dragon NaturallySpeaking to navigate through LJ. Some links are very difficult to access and not voice recognition (VR) software friendly.

Full description of the idea
For example, I have to hover over the "Journal..." link to open up the "Recent" link. Using Voice Recognition software, I say, "Click Recent." to activate the link, but to get it to be visible is a pain, as I have to deftly command the pointer to pass over the "Journal..." link.

Also, there are far too many links on each screen, and mispronouncing a word usually takes me to a random, bizarre screen, and all my typed out text is lost when I come back.

Also, the ALT text that you enter into each Image is what VR software uses to activate that icon/graphic-button. Please keep these ALT text tags simple, and regular English words.

Have you thought about making LJ more Voice Recognition friendly?

• disabled users will be able to work easily
• users afflicted with RSI usually use VR software

• may require large amount of rework

• Make each link visible initially, should be no need to hover over one link to reveal another
• simplify ALT text used to reference graphic-buttons and icons
• try and avoid duplication of links/ALT text tags in each screen

Title
LJ named posts vs numbered *more*

Short, concise description of the idea
It'd be nice if you could specify other document names in the LJ namespace of your account instead of ####.

In addition, it would be nice if the display processor would parse out Wiki like syntax to reference these.

Full description of the idea
It'd be nice if you could specify other document names in the LJ namespace of your account instead of ####.

In addition, it would be nice if the display processor would parse out Wiki like syntax. This would allow referencing past posts of signifigance without having to find the post so long as it was properly named in the past.

This could be done manually through setting memories, and searching, etc. but a WikiWiki like syntax would be more useful.

Something similar to <lj-wiki name="MyFavoriteDay">

Or maybe, if the concept of "wiki" might bring about too much unwanted traffic, calling it "vanity named posts for paid members" or such to allow you to assign a name on a post, though it would still be nice to be able to pre-name it, and then if you select the link, it brings you to an update full with the vanity name pre-filled.

An ordered list of benefits

• convenience of refering to past posts
• organization of ideas

An ordered list of problems/issues involved

• Potential for heavy use if allowed for free members
• Requires modification to LJ code
• Requires interest by coders

An organized list, or a few short paragraphs detailing suggestions for implementation

• Should be pretty self explanatory from above.