this is my firts post here ever.
I have to develop an aplication for a group of people with special needs. The functionality is really trivial, however, i have no clue of how to do the interface for them to be able to use it.
Their intelectual habilities are perfect, they are actually studying high school, but one of them types with his nose which needless to say, is very dificult and another one types reaaaaaaally slowly with only one of his fingers and neither can use the mouse.
I was wondering if i could use javascript to develop a usable interface, based on huge grids or something like that or maybe you guys have a better idea.
Political incorrectness aside, why don't you ask them? You're talking about accessibility here, if they're using computers they must be able to tell you about what they like or dislike about user interfaces that they've encountered.
I'm going to split my answer into two parts - design and implementation.
From a design perspective, it's important not to be intimidated by the fact that the users use a computer in a different manner. Treat this like any other project. Observe how they currently use other apps, and ask about the kind of things that they find helpful, or have difficulty with. If they claim nothing is difficult, ask a teacher or assistant, who will be familiar with the kind of things they struggle with.
Once you've started implementation, try an idea and get initial feedback. If you simply ask how they find the prototype, they'll likely say it's ok. Instead, try observing them using it without saying anything or giving guidance. If they get stuck, let them find their own solution to the problem. If appropriate, you could ask the user to speak their thoughts out loud (e.g. "I need to save this form, so I'm scrolling to the bottom, and clicking save").
On the development side, try to use web standards (valid HTML, CSS and Javascript). People often point to the "Web Content Accessibility Guidelines 2.0" (WCAG2) but this is quite turse and hard to understand; there are many more friendly articles on "Web Accessibility".
Someone with a physical disability is likely to use an alternate input device, such as a "Switch", onscreen keyboard, head-tracking device, a device for pushing keys on the keyboard, or speech recognition. Many of these methods involve simulating the keyboard, so by far the most important thing is to consider the accessibility of your site without using a mouse. For example, try tabbing through the page to see if you can access all elements in a reasonable amount of time. Consider using the acesskey attribute to provide an easy way to jump to different parts of the page (using 0 through 9 is often recommended so you don't interfere with browser shortcuts).
Also make sure that no part of your site is time-dependant, as different users may take different amounts of time to perform a task. For example, don't use the onchange Javascript event to update a page based on a listbox selection. Ensure you have alt text for images, so it's accessible for speech recognition. make the pages short enough so that excessive scrolling isn't required, but not so short as to require following lots of links.
Those are just some ideas to get your mind going in the right direction - but there are many accessibility resources on the internet - steal freely, and don't reinvent the wheel.
I realise I haven't addressed your question about Javascript - that's because I think it's probably one of the less important considerations. If possible, use Progressive Enhancement techniques to make the site work with and without Javascript. You might also look into the WAI-Aria standard for giving semantics to your Javascript.
And finally, to reiterate my initial point - make something simple, show it to the users, tweek, and show again.
It doesn't really matter what technology you use. Use whichever suites you.
But, make sure that you make UI components BIG in size(Bigger buttons, bigger font, bold font, coloured font(are there any colour blind?). This is for the ease of use of people (you said someone types with nose).
Also, better to have audio as informative source along with the usual screen display whenever some wrong action is performed on the application. This way visually impaired people will be assisted more.
Do it well, you are doing a divine job.
The first thing that you should read up on is the Web Content Accessibility Guidelines written up by the W3C.
In a nutshell this document describes the basic principles for people with disabilities in general.
For your needs regarding persons with special needs, you might want to look at Jakob Nielsen's article on Website Usability for Children, wherein principles of web design for young children or people with otherwise limited cognitive ability are outlined.
Related
How can I ensure (or try to make) web access available for all - who may have a variety of disabiltes?
Any advice for any standards or web sites that could give me some pragmatic advice for the design of a site?
There are a number of considerations you need to address here, if your website isn't catering for a specific disability then you have to work on a broad range of features. In this situation the first thing you need to remember is that you sadly can't cater to everyone. Look at the list below and identify which of these disabilities you can sensibly cater for
Visual: Visual impairments including blindness, various common types
of low vision and poor eyesight, various types of color blindness;
Motor/Mobility: e.g. difficulty or inability to use the hands,
including tremors, muscle slowness, loss of fine muscle control, etc.,
due to conditions such as Parkinson's Disease, muscular dystrophy,
cerebral palsy, stroke;
Auditory: Deafness or hearing impairments,
including individuals who are hard of hearing;
Seizures: Photoepileptic seizures caused by visual strobe or flashing effects.
Cognitive/Intellectual: Developmental disabilities, learning
disabilities (dyslexia, dyscalculia, etc.), and cognitive disabilities
of various origins, affecting memory, attention, developmental
"maturity," problem-solving and logic skills, etc.
The easiest here is the Seizures, eliminate flashing / strobing content from your site, or more importantly if you cant put up a warning before displaying this type of content.
Users with Motor / Mobility issues may have problems interacting with content on your site that requires a high amount of precision, this can be helped by increasing the size of your UI elements, or allowing the user to resize these elements if needed.
Generally make anything clickable as large as is feasible and if you have elements that have features such as drag drop, make the drag handles large so the user doesn't have to click a tiny area.
Auditory is also a fairly easy consideration to make, at the least simply provide text alternatives to any media content your site may have, for larger sites using video then considerations such as sign language may be an option.
Visual is probably the most common consideration web developers need to make. Firstly partially sighted users may want to increase the text size to your page, so make sure that your UI can cope with this. Use clear and readable fonts and make sure there is contrast between the background color and the font color.
Color blind users may wish to change your site color scheme to meet their needs, you can find information easily on the types of color blindness and develop a couple of alternative CSS styles to meet these needs. Also a high contrast option for everything on your site may benefit partially sighted users.
Cognitive / Intellectual is one of the harder considerations to meet, so look at the individual disabilities. ADD for instance makes it hard for a person to focus and makes them easily distracted, considering this think about advertisements, they are designed to distract us and draw our attention, thus by limiting advertisements on your site you can get rid of the ones that flash and scream Click ME!.
Dyslexic users may struggle with reading huge chunks of text which also fits in with considerations for partially sighted people, here you could have an audio option so the text is read aloud to the user.
One more consideration here is the use of color in your website. It has been proven that certain colors can stimulate emotions, for someone with emotional or developmental issues using colors that are considered calming vs ones that excite (reds for example) may improve their experience of your website.
All of the above are design considerations, looking at the development (Code) next there isn't too much you can do, most of the considerations about your code are because of third party applications interacting with your site.
Generally make sure your code is well formed, correct tags / closing tags etc. Make sure it is valid HTML / XHTML / CSS etc if you can validate to the strict standards it wont hurt your cause. Tags such as links / images should have appropriate Alt text to describe what the element is, for instance alt="image1" is fairly useless to a screen reader but alt="Image showing ...... clicking this will take you to....." is useful.
If you can find some trial software grab yourself a screen reader, load up your website, close your eyes and try interact with it, its going to be hard but at least you can see how your user will interact with your site and more importantly you can use the screen reader to check your site actually gets read the way it should.
There are plenty of 3rd party plugins you can integrate with your site to aid your users too, so look into those, things like the option to magnify text or read aloud with just a click will be well received as long as they are not too intrusive to your non disabled users.
Helpful links
http://www.w3.org/TR/WCAG10/ The W3C Disability guidelines are a good place to start
http://en.wikipedia.org/wiki/Web_accessibility Wikipedia web accessability
http://www.etre.com/tools/colourblindsimulator/ Allows you to see how images will appear to colourblind users
http://colorfilter.wickline.org/
http://www.w3.org/WAI/ W3C Web Accessability Initiative Guidelines
Section 508 is the section of the law that requires that US government websites be accessible.
More information is here, including best practices on making content accessible to all.
http://www.section508.gov/
Generally you should support screen readers by using semantic markup, and avoid flashy content and audio -- these are usually impossible or just difficult to make accessible.
You should also look at web typography guidelines and look to hiring a good designer. Poor color schemes, typefaces, and font sizes make reading on the web much harder than it needs to be.
If you're from the UK, from a legal POV you want to be looking at the Equality Act (which replaced the Disability Discrimination Act).
The foundation of web accessibility is based on the graceful degradation/progessive enhancement model (sounds more complicated than it is!). A List Apart wrote a great article on it some time ago.
A good starting point for web professionals is the RNIB's Web Access Centre. Obviously this mainly deals with those user who experience visual disability, but it's a very useful resource.
Web AIM is also a good site for resources/articles although I'm not sure how often it's maintained these days (still, the information there is relevant).
There are far too many individual little things to bear in mind when developing accessible interfaces, but if you take the time to read some of the articles on those sites, you'll pick up the fundamentals which will then lead you onto the more nitty-gritty things.
Accessible development is about a change in mindset as much as learning the nuts and bolts. You need to to be constantly asking yourself "How might other people use this? What barriers might be in their way? What browser are they using? Does this work without colour/JavaScript/CSS?". Learn how to take your site apart and see if it still works.
Web Content Accessibility Guidelines 2.0 (WCAG 2.0) is the W3C Recommendation from Web Accessibility Initiative (W3C/WAI).
An overview can be found here: http://www.w3.org/WAI/intro/wcag20
There are very broad Principles as well as precise Techniques (for HTML, CSS, JS, Flash, etc) and the intent of each and every criteria. These aren't documents meant to be read at once and you'll want to learn more from tutorials and articles found on the web (archives at 456 Berea Street, WebAIM, videos about accessibility)
The W3C Quick Reference guide to WCAG 2 lists all of the relevant techniques you'll need to implement the WCAG2 principles and guidelines that Felipe mentioned, with code examples if appropriate on the individual technique pages. If it's all a bit too technical for you, WebAIM's checklist is the same thing only in plain English.
Unfortunately there's no magic wand for getting sites to be compliant. You have to go through each bit of content and test it and modify it if necessary. Luckily, even some small improvements can make a big difference.
A lot of good answers, but I can't help adding my input as well.
If you want to ensure a website is disabled friendly, there are a number of considerations that should be taken. One that I have not seen on here (perhaps because I skimmed) is to ensure that you use high-contrast colors, with a solid background behind text.
However, you should NOT use white on black or white on black...dyslexics commonly cannot see those colors. Use an off-white for background or text.
Also, make sure your text is large. Ensure as much of the content as possible is standard text, so that text-to-speech programs can "read" the website. Text-to-speech cannot read images. Text links instead of buttons would also be advisable, for the same reasons (though there may be a means of associating text with a button for these scenarios...?)
This is a best-practice topic.
I saw it as a prefer method for some web developers. Instead of doing the CSS layout from scratch, they start a photoshop mockup first and then decode it into CSS.
What do you think about this approach?
Best to all,
Mockups are great, but I don't know if photoshop is the very first thing you'd want to try for the purpose -- at the very start, when you're just trying to get a logical layout for the various pages of the site (before refining it in terms of looks &c), a whiteboard with dry-erase markers and post-it notes affords for very fast, repeated mock-up rearrangements for the early brainstorming. Once there is some reasonable agreement on one (or a very few) possible arrangements of information, then visually more accurate tools enter into play.
BTW, just don't forget to photograph the whiteboard before changing it (any decent cellphone will do, you're not trying for high quality here;-) any time there are ideas or suggestions you may want to revisit or ponder in the future!
It is fast. This is why i always use this method. You don't want to spend the time building cross-browser CSS until you are actually set on a layout.
Most webdesign graphic artists work this way.
Many programmers simply find it a waste of time.
It has advantages, and disadvantages.
Advantages:
Many graphic artists grok photoshop/illustrator more than they do dreamweaver.
Customer gets a preview of the final product that works everywhere: mac, pc, firefox, ie, safari, whatever. Sending an html preview in early stages of production with developers using firefox and customer using MSIE always stirs up trouble.
And don't think to be on the smart side, scribbling MSIE driven html. Starting with non-standard html and converting to standard is more painful than doing it the other way.
There's one more catch: many web site customers tend to have a Mac and use Safari. Web committents tend to have a stronger taste for graphics than the average, so the chance to bump into Mac maniacs is higher in this sector than in others.
More design alternatives can be prepared spending less time on each one. This could be a dramatic advantage while dealing with murky clouds of executives with no designated decision-makers on the customer side. Alternative mockups will be passing hand-to-hand until general consensus is reached on one design or the other.
Disadvantages:
"Cutting" the graphic design into html becomes an additional work and it's not clear who's gonna pay for that extra time.
It favours graphic-centric, and rigid, design workflows. Customers agree pre-emptively on a given preview and that's what they get by contract. Every graphic modification means money, behaviour and programming instead tend not to be well defined, or worst, ill defined by the mockup.
The quest for pixel perfect cross-browser adherence to the mockup may drive you insane. If you agreed on a given rigid design with the customer, that could become a dire issue to pursue.
Dirty CSS tricks shoe in into your design. Using an HTML mockup, the customer would have approved a design driven by code with less tricks in place.
Anyway, I wouldn't suggest photoshop for a mockup, but inkscape. (or illustrator, if you worship adobe by burning piles of money into magic circles at midnight)
A scribbling stage is good too, while discussing the contract live with the customer.
I prefer pencil and paper to felt-tips, and I webcam shoot ideas for archiving and email forwarding. When it comes to scribbling, anyone does what feels more natural.
Not doing any and rely onto sample site examples and screenshots for graphical reference is always an option.
If you're productive that way, why not? Not everybody manages to envision their Web site perfectly as they're typing in a bunch of angle brackets.
More seriously put: It's your job, so it's your responsibility to do it in a way that allows you to do it effectively.
When prototyping, it's important to choose the right fidelity. This article from BoxesAndArrows provides a nice introduction to the various options and their uses.
I particularly like this line by Bill Buxton which the article quotes:
There is no such thing as high or low fidelity, only appropriate fidelity.
In this TechTalk by the Facebook Design Team, they mention how they use Photoshop in their design process (IIRC it's somewhere midway through, but I can't seem to forward through the video).
I am a web programmer who knows html and css fairly well. I can use a graphic program for it's basic functionality, but desinging a complete graphical web site is not my thing.
I let a graphic designer use his or hers graphic program to create a nice looking layout, and than code the website by hand in html and css.
It works for me, and gives my customers a design they like (cause a graphical designer will always make a much more nice looking design than most web programmers).
Agile methodology would suggest something easily modified in consultation with the customer. Dave Thomas in Agile Web Development with Rails suggests scribbling on paper. But anything has got to be better than chipping away directly at handmade CSS unless you really know what you want.
I was thinking about saying "scribbling might not cut it for a formal presentation" but the awesome SO crowd beat me to it in the comments...
Personally, and at every webdev firm I've worked at, I've always mocked-up in photoshop first. Jumping straight into CSS and markup is more of a bottom-up approach and makes sense to a lot of programmers but in web development you have to keep in mind that there are aesthetics to consider and a creative direction to follow. It's not enough that your product is functional, it needs the input of a professional creative-director/graphic-designer in order to make the product pleasant to look at and use.
In my experience, the problem has always been wrestling with inflexibility of team-members. Graphic designers who are aesthetics focussed and refuse to compromise their design integrity; which sometimes results in impossible or extremely difficult and un-semantic layouts. Developers who flatly refuse to compromise the integrity of their code where there is a workable solution - which might be a little less elegant. The key is to have a creative team who is intimately familiar with CSS and what is and isn't possible and an engineering team who have an appreciation of the importance of design and aesthetics.
In my freelance life (having had the benefit of working in both camps) I find it much easier to mock-up in photoshop first because I know what I can and can't do. And photoshop mockups are a lot easier to change on client feedback than are CSS and markup. Also, if you can show your client a mock-up, they feel more secure because they know that their money is going into a well planned project with a definate direction.
Hope this helps!
I've never really learned much about accessibility but it seems like an important topic.
When you build a website or piece of software, or when you're talking to a client about a website, where does accessibility come in? Or from your experience, if you don't have accessibility in something you've built for a client, do you get a lot of requests to include it, or does it limit you in some financial way?
What are the numbers, I guess. What's the return in your business, how many people have you talked to that need it? Do you yourself need accessibility features?
I do mainly Flex/Flash and it seems like I'll have to do a bit of work to have full accessibility.
Thanks for the help.
As a person with a disability myself, I am consious of adding accessibility features when I write software
Accessibility is an area of software design concerned with making software user interfaces avvessibile for people with physical or mental disabilities or imparements. Different people have different specific needs and you can't be expected to cater specifically to each but there are some broad groupings
Visual Imparements:
This includes blindness or color blindness. To assist in this area consider providing "good" alt text (clarified blow) and hints so that screen readers can present a view of your content that makes sense aurally. Providing easy access to links to raise text size and/or access to some high contrast stylesheet options is also a good idea.
Non-Mouse Users
There are a huge number of conditions that can prevent one from being able to successfully mouse, it took a few years for me and my brain, which is somewhat unreliable when it comes to spatial relationships to pick up the skill. For these people keyboard access is really helpful, I don't work in the web space so I'm not sure if there are standard keys to use, but these are communicated by screenreaders and tooltips so having any is better than none.
Hanselminutes episode #125 is quite educational. He talks with a blind user about accessibility on the web and in generalAccessibility is omitted from a lot of design processes, either because businesses don't have an immediate need for it and therefore don't consider it at all, or consider it a low priority feature. Leguslation in various countries has helped a bit in this regard, but the real problem is that accessibility in general is usually an afterthaught to the design process,
1"Good" alt text is judicious use of alt text that accentuates the content or purpose of a page, navigation elements should have alt text describing where interacting with them will take the user, similarly, things that aren't content, like spacers should have no alt text at all, because there is nothinng worse then hearing "Foo's widgets spacer spacer spacer spacer spacer nav_Products spacer nav_support"
I think accessibility is usually completely forgotten about (either implicitly or explicitly dismissed beforehand because of issues like cost) in most software development projects. Unless companies (or individual developers, more likely) already have experience with either people with disabilities or with writing software with disabilities of users in mind.
As a developer I at least try to do keyboard shortcuts correctly in software I work on (because that's something I can easily dog-food myself, since I try to keep hands-on-keyboard as much as possible). Apart from that it depends on whether there are requirements about accessibility.
I do think this kind of thing is part of "programming taxes", i.e. things that you as a developer should always be doing, but...
I am only aware of this - at least more than the average developer, I think - because I have once written software for a software magazine on floppy disk, or Flagazine. This was in PowerBasic 3.2, grown out of BASIC sources in a magazine, making these sources available by BBS and disk, eventually growing a menu around the little applications to easily start them, etc.
One of our primary users (and later members of the editorial staff) was blind and was appalled when we switched from text mode to an EGA mouse driven menu, as his TSR screenreader software couldn't do anything with graphics. It turned out that his speech synthesizer simply accepted text from a COM port. It had a small (8K I think?) buffer that would be instantly cleared on reception of (I think) an ASCII 1 character. And that was it.
So we made the graphical menu (and most other programs on the Flagazine) completely keyboard accessable at all times and in the graphical programs we use a small library I wrote to send ASCII text to a configured COM port. This had small utility methods like ClearBuffer(). With this, and the convention of speaking possible menu actions when pressing the space bar, made all of this software accessable to our blind users.
I even adapted a terminal application for my HP48 calculator (adding a clear buffer/screen on ASCII 1) so I could use that to emulate a speech synthesizer. I would then test all of our software in each Flagazine by attaching my HP48 with the emulator running, turning off my computer monitor and trying if I could use all the software without seeing anything.
Those were the days, about 12 years ago... ;-)
I am a blind individual so have to develop with accessibility in mind if I want to use my own programs. I find my self focusing on accessibility based on the type of application I’m writing. When doing command line or mainframe applications I don’t think about accessibility since those environments are inherently accessible. With web based applications I have to give some thought to accessibility but not a lot. This is mainly because I write simple web applications for limited use so don’t have to worry about making the interface appealing, just usable. The area I spend the most time focused on accessibility is desktop applications. For example using .net I need to make sure accessible properties are set properly and that labels are in the proper position in relation to a text box so my screen reader can find them and associate them with the proper control.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
Concerning pages that build a web application:
Lately, I have found myself creating web pages that are simpler than the ones I used to. Before, I would try to jam as much functionality into a single page as I could to prevent from having lots of pages.
I am starting to realize that this was just making things way more complex, convoluted, and confusing than it had to be. Why not have more pages? I think the reason that I was doing this was because I didn't want the user to have to browse to other pages; just to have all the functionality they needed on a single page.
Well, these good intentions turned into an overly confusing interface for the user and very unmanageable source code. I am a new developer and I am trying to be very reflective of what I am doing so that I can improve. If it makes a difference, I am developing in ASP.net (though these are probably considerations for any platform).
My questions are:
Am I overthinking these things?
Has anyone else found themselves doing this?
Where is the happy medium?
There is no expert who can give you a rule that works in all places at all times. I have been known in my industry for years for "easy" interfaces and we've won significant amounts of business for it (as well as 5 "Best in Class" awards). I have also had people within my company and outside of it tell me - for years - that they like my work but wish that I would "jazz it up" with more graphics and such. What always amazes me is how little connection people see between the two.
So...a few rules of thumb:
A page should do one main thing.
A page may well have multiple links related to the main thing
Menuing and link layout should be consistent across pages
Simpler is better than more complex
Pages should be visually appealing and inviting
Rule 4 is more important than rule 5.
For example, my product provides an interface that lets people define classes and events to be displayed in a calendar. I could have one page that lets you Review, Add, Update, Delete and Edit the classes. Indeed, in some simpler areas, I've used the gridview to let people manage everything in a grid. However, classes have too much information to do this and still follow the rules above.
So,
The main idea is: "Here is a list of classes for this location"
The links are "Add New" shown above and to the right of the grid, Change and Delete are links within each row. This is consistent across the app.
Menuing for the system as a whole is always across the right/top. Nothing else appears on the class/event page except for standard elements common to all pages (a logo, a header, a footer).
The grid is nicely styled but there are no spurious graphics (4,5,6)
A few last things about UIs and graphic design.
First, develop your own vision and be consistent across pages and apps.
Second, do not be afraid of simplicity.
Next, when soliciting advice from others keep in mind that you do not want their advice - you want their impressions: you want to understand the way they perceive the interface. Advice is sometimes good but, more often than not, actually harmful. In my experience, everyone thinks that they are a UI expert.
When you do your hallway (or formal) useability testing you should discount almost all advice to the effect that "you should make that stand out more." As you'll see, it will quickly become "and that," "and that," "and the other." If you follow this advice, you'll end up with a mess due to Brittingham's first rule of design: If everything is important than nothing is. (There you go: when explaining why you can't make someone stand out more, just tell them that "it violates Brittingham's first rule of design!")
Hope this helps!
You hit the nail on the head. Use the KISS principle. (Keep It Simple Stupid)
I've done this in the past as well and not only does it make for a hideous UI, but confusing as to what operations you can do on the page due to having too much functionality. I've often found in testing that I did not have enough checks to see if the user could perform a certain operation based on the state of the data.
It's easy enough in ASP.Net to write several pages that do simple tasks and then link them together with Response.Redirect or Server.Transfer. Now all I try to achieve on any given page is what the design specs say. So if my page is just a search page, that's all I give. If the user wants to see the details of an item that was returned in the search, then I send them to an itemDetails.aspx page.
You've broken a wall that most software developers have, the one that was blocking your view on usability before. A lot of developers don't really think about it and try to make it easier for them by stuffing functionality in one window, web page or whatever.
The thing is once you start designing software from the user's point of view, i.e. making it easier, several things start to become clear. One is the issue of code maintenance, that code is easily more managable to work on if you don't stuff everything in one giant class or whatever travesty you've been doing. The other is usability itself, that you start to think how the user is actually using your application through the graphical interface. Third is avoiding requirements or scope creep where you stop developing functionality that the user doesn't need.
We as users want simplicity partly because we don't want to spend most of our time muddling through a bad UI when we can get our work done faster with a simple and slick UI. That makes it for us software developers the right thing to do, to think through your design on all levels... that and specs always lie.
Definitely agree: most attempts at writing pages/forms that do too much have resulted in
bugs and rewrites. Problems occur with keeping all parts valid/synchronized,
excess managing of users' expectations ("I've entered a bill number here and clicked "find person" there but it gives an error message. Why?") when the two are logically separate. These questions cannot arise if only the valid options are visible,
Formatting/layout issues: In ASP.NET pages, trying to layout independent User Controls turns out to be a nightmare ("But we really want all the buttons vertically aligned!" in separate user controls. Good luck with that.)
I'd consider webpages with more than one functionality only if the target audience consists of domain experts, i.e. people that need lots of functionality on one page for better productivity (think data-entry or financial software with lots of variables).
Even then, most of the time, it's possible separate pages into single units.
No
Yes - me
I found the happy medium was to use Masterpages, and using it in a way that was familiar to IFrames. That I could have a lots of functionality combined well together. There is a more interesting way of doing this with WPF/Silverlight called Prism
The amount of functionality on a page is usually not determined by you but by your customer. If the customer demands a single page to update some VeryComplexObject, you're likely to end up with an aspx page that has a significant number of lines. Main reason is that you simply have a lot of event handlers for all actions on the page.
Whether that page is complex is entirely up to you. You should always attempt to make your code-behind file as simple and clean as possible. Some suggestions in that direction:
Move all business code to another application layer.
Use ObjectDataSource for providing data to data-bound controls such as ListView, GridView, Repeater, ... Delegating loading of data to a dedicated object prevents a lot of overhead in your aspx.cs file.
Another suggestion is to use user controls to implement portions of your page. You would usually only do this when you can reuse the user control, but it can also be of great help reducing page complexity (both of your code-behind file as well as your aspx).
Sometimes I think we are all guilty of forgetting just who it is that we develop our applications for. It isn't always easy as a developer to be able to take a step back and have a look at your application as a user might do so. This is why big companies employee hundreds of people to do this for them and they don't always get it right.
Usability is a massive subject but it is defiantly something that all developers need to keep in mind. It has taken me a long time to learn this but when tackling any development task I always try to think about how my users are going to interact with what I am writing. This will make a difference to all levels of your development.
I would suggest reading Don't Make Me Think by Steve Krug. This book won't take you an age to read and it puts across some fantastic ideas that can help you to develop applications that are much easier to use and understand.
I always find that once I have thought about the user experience the decisions about what my web pages are going to do and how they are going to interact are much easier to make.
Maybe you should ask the people who are using your site. Or better yet, just watch people use your site. I think that would tell you if your site is designed well, or if you need to change it.
I understand that some countries have laws regarding website accessibility. In general, what are the minimum requirements that a website must meet to be accessible, regardless of country? Or, in lieu of minimum requirements, what are some specific things that websites should have to make the accessible?
W3C publishes Web Content Accessibility Guidelines:
http://www.w3.org/TR/WAI-WEBCONTENT/
If you want a quick summary list, look for the yellow-highlighted lines in that document. Each guideline is also broken down into specific requirements ("checkpoints") in one of three priorities - to claim any kind of accessibility under this scheme you must satisfy all priority 1 checkpoints, but they're "necessary" rather than "sufficient" conditions.
Looking at your pages in lynx is also a good measure - if it won't render in text, chances are good that a screen reader will have a difficult time of it too.
I recommend A-prompt for testing of Accessibility.
It is free and it can really help.
I also recommend Mark Pilgrim's online text - Dive into Accessibility.
It's not a binary question, and there's no silver bullet. Making sure you follow at least the basics of WCAG and testing in a couple of screen readers and without the mouse will probably be the most effective use of your time. If at all possible, test with real people with real disabilities, they have a perspective that is hard for fully-abled people to attain.
Well, obviously the law in different countries varies vastly. In the UK, for example, we don't have any specific web-accessibility laws, but no service is allowed to discriminate against someone with a sight or hearing impediment, insofar as it relates to functionality.
In light of this, a simplistic way to design would be to ensure that your website is readable by screen-readers, can be tabbed through successfully and in a logical order, and allows the scaling of screen elements (including images and font sizes) correctly for those who require web-pages to be magnified.
In addition, your website should have functionality fall-backs in place for any JavaScript and Flash, such that if they were turned off (such as is the case in many screen readers) all functionality is still usable. Don't rely on WAI-ARIA for JavaScript accessibility, as it isn't standardised, and it isn't widely supported.
Of course, this doesn't necessarily cover every possible law, but it's a good starting point. If your website meets the above 'criteria', you're likely to have a good level of accessibility. There is a test for accessibility, of sorts, following WCAG but it's by no means 'conclusive' for what is an acceptable level of accessibility in each individual country.