We are contracting an external consultant out to generate XHTML (Transitional) and CSS for most of the major pages of a new project we are currently working on.
I've been asked to put together a list of guidelines for them so that we can be sure that a certain level of quality can be expected. As a bit of technical background, we will be incorperating the raw HTML they provide into an ASP.NET web forms application (utilising the usual master pages / external stylesheets / jquery). Javascript should not be a consideration, but formatting and organisation of CSS should be.
I've made a start but quickly realised that this is probably not a unique situation and that a tried and tested list might be out there somewhere that I can at least use as a template! Has anyone got any experience of this?
From a technical standpoint, pages must pass validation is probably the first test I'd have.
I would expect the site to be able to be used by someone with JavaScript disabled, and someone using a screen reader (this is quite a good one as it should also highlight issues with inappropriately used tables and other things such as missing image alt tags, inconsistent use of header tags etc.).
One good test I always make for myself is opening the page and ctrl+scroll.
The zooming gives you an immediate idea about how flexible and liquid your design is.
In IE this tends to fail no matter what, but there you could also try to make the font bigger and see what happens (pay attention to buttons stretching vertically for example)
Give them a list of browsers (browser version and OS) you expect them to support.
Should the accessibilty guidelines be adhered? You could agree on supporing some of the points in the Checklist for Web Content Accessibility Guidelines. The list is actually quite usefull, since it will not only insure that your site works for people with disabilities but also for browsers without JavaScript, CSS, Images. The list also contains some general good practices for building sensible web sites.
Since you're using ASP.NET make sure that they only include one <form> per web page. Or at least, be prepared to make some workarounds, if you allow them to use more.
If you're planning on using AJAX show them ASP.NET AJAX Control Toolkit so that they don't spent time on things that have already been built.
I would insist on that they use some proven frameworks like YUI css reset and jQuery.
One thing that makes passing an HTML / CSS template between multiple front-end developers is proper structuring and indenting of the markup. The same way books are broken down into volumes, chapters, paragraphs, sentences, words, spaces, and periods, there is a hierarchical structure that makes HTML and CSS easy to read (and on the other hand a way of coding that makes things a total mess)
As a rule of thumb:
<body>
<div id="first">
<p>
Some text goes in here...
<p>
<ul>
<li>A list item</li>
<li>A list item</li>
<li>A list item</li>
<li>
<ul>
<li>
A link
</li>
</ul>
</li>
</ul>
</div> <!-- #first ends -->
</body>
This kind of adherence to structure can really cut down on time by making scanning code super easy for whoever is working on it– regardless of whether they wrote it or not.
Apart from validation the following points should be keep in mind
- Accessibility (Who are the audience)
- CSS based design (Where semantics are well designed)
- Be consistent with your naming convention (css and id naming. This will be beneficial in the long run when any change needs to be made, when a new css has to be applied etc).
Check out the following best practices from yahoo developer library...
http://developer.yahoo.com/performance/rules.html
Also since you are using ASP.net be careful when naming usercontrols as the client side ID that is generated could be quite long and unexpected(asp.net generates the id at runtime);
Some good info could be found at
http://woork.blogspot.com/2008/11/useful-guidelines-to-improve-css-coding.html
Indeed, make sure that the page passes validation.
Also pay attention to semantics, the page should be in a logical order when CSS is disabled (which is the case for some browsers and screen readers). Make sure that headings are actually <h#> tags and that all images have appropriate alt tags. Also make sure tables are only used to display information and are not used for formatting. The menu should be constructed as a list not as divs (semantics).
Related
I am aware than in many cases an HTML element does more than simple affect the page semantically, and the additional functionality make it a no-brainer choice. For example, although there is a textbox ARIA role, it is nearly always preferable to just use an <input> or <textarea> element whenever possible.
However, for "semantic" HTML elements, I can't find any information indicating that they do anything more than supply a default ARIA role for the purpose of accessibility and provide some minor code readability enhancements. For example, the only purpose of the <main> element (as far as I can tell) seems to be a "shortcut" to avoid typing out a few extra characters <div role="main">, also resulting in a slight readability improvement.
So, is that tiny readability improvement really the only reason to use <main> over <div role="main">, or are there other reasons I might be missing? Is there any conceivable reason that I would ever want to prefer the latter?
Semantically structuring your page with semantic HTML makes the contents machine-readable for the browser, browser extensions, search engines and other tools without extending their code to cover ARIA as well.
This is especially important for accessibility, as assistive technology are such tools, which might attach additional functionality to certain roles.
The browser’s read mode, for example, can easily extract contents from a <main>. Also handling role attributes makes coding it more difficult.
Also writing user stylesheets to improve accessibility is way easier if you don’t need to cover ARIA attributes.
W3C has written a complete doc about using aria : Using ARIA by W3C
The first rule of ARIA explains that you prioritize the native HTML element or attribute with the semantics and behavior already built in.
In your example, the element is a native HTML element with an implicit main role. You can give a look to the complete list of implicit roles of HTML.
I'm tasked with evaluating some legacy web pages (classic asp) for accessibility. You can assume the HTML is not perfectly formed and that it's loaded with inline javascript and that we make use of javascript libraries that vomit HTML to create dynamic features. It's a circus in there.
While I recognize that the obvious answer is to re-write the page(s), that's not an option in our given time tables. So I'm trying to find the best way to make the pages work with a screen reader. Here's what I think I know.
We can use JAWS scripting to instruct the browser how to read the page.
We can use ARIA attributes to give the pages better organization and structure.
Specifically, I'm trying to figure out:
Question 1) If a JAWS script is present, will it be used exclusively by the browser/screen reader and ignore any improvements I make in the underling HTML structure?
Question 2) Could some well-place ARIA attributes give the page enough structure so that the default screen reader properties will work in an acceptable manner (without a JAWS script).
Question 3) I suspect the tough answer is that I would need to do both, which I'm trying to avoid because we barely have the capacity to do just one. But we don't want to lose a customer, of course. :-(
Many thanks for any input.
Instead of explaining only to JAWS how to access your pages, use JavaScript to explain it to any Assistive Technology (AT) for the web. I expect the same effort, while it will profit way more users.
In a JAWS script you would need to describe ways to access DOM nodes that are not accessible. That would include
speaking out information that you have to find elsewhere on the page
adding keyboard navigation where it's missing
Both can be done in JavaScript, probably even easier (you'll need to address DOM elements).
What you will need to avoid is restructuring the DOM and changes to classes, since those are most likely used by the scripts that generate them.
But I'd expect that adding attributes and keyboard handlers will do no harm to the existing scripts. Beware of already existing handlers for focus or keyboard events, though.
I would recommend making a list of attributes and handlers you suspect to conflict with the existing scripts, and searching the scripts for these, like onkeypress or onfocus event handlers.
The absolute best way to make your application/site accessible is to use semantic HTML. It doesn't matter if that HTML is generated by asp or jsp or whatever.
If you have a table, use a <table>.
If you have a heading, use an <h2>.
If you have a list, use a <ul>.
Use <section>, <article>, <nav>, <aside>, <header>, <footer>, etc
That's how you create structure on your page that a screen reader user will appreciate.
If you can't use native HTML, then fall back to ARIA, but treat it like salt. A little bit greatly enhances the flavor but too much spoils the meal.
If you can't use a native <h2>, then make sure you use the appropriate role and attributes.
<div role="heading" aria-level="2">this is my custom h2</div>
If you can't use a native <header>, then make sure you use the appropriate role and attributes.
<div role="banner">my header stuff goes in here</div>
I would recommend totally forgetting about JAWS scripts. It doesn't matter if that's what the customer thinks they should focus us. It's not about that customer. It's about that customer's customers. The end users. They should be able to use whatever screen reader they are used to using and most comfortable with. That's the whole purpose of accessibility - making the site usable and accessible by as many people as possible using whatever assistive technology they are used to using.
Following the Web Content Accessibility Guidelines (WCAG) will lead you to that result.
I have a messageboard and one of my users has written a greasemonkey script to stylize various elements within the page. He did a great job with it but in order to make his job easier, the first step in his script is to parse the current page and add several css classes to almost all html elements on the page. most of them aren't used to style the page at all, but instead to make it easier for him to query the couple elements per page that he will actually modify. for example class="thread_started_by_user_123 thread_with_456_posts thread_with_789_views thread_last_posted_in_by_user_12345" etc etc
is this a standard practice? are there any downsides to adding lots of unnecessary css classes, either in javascript, or on the server if i were to add them to served pages too.
This looks to be using classes to embed arbitrary metadata into elements, which is certainly not what the class attribute was designed for. Given that its effects begin and end with a greasemonkey script and are thus localized to the client, it seems a harmless enough hack, but not one I'd advise duplicating on the server side.
HTML unfortunately doesn't provide much in the way of alternatives when it comes to metadata other than sticking in invalid attributes, so there is a mechanism that does add semantic meaning to the "class" attribute within existing tags -- namely microformats. There's a lot of breathless buzzwordy hype around microformats, but overall they do revolve around a best practice for areas where going all-xml is out of the question.
In terms of semantics, yes there are downsides. If you have classes that aren't descriptive of what the element actually is and are there for styling purposes only, this can hurt you down the road should you decide to redesign and/or restructure.
for instance, BAD:
<div class="header red left-side">
GOOD:
<div class="header main current-event">
If there is no associated style with a class that's assigned to element, then I believe the browser will just ignore it. So it will not increase your page processing time a lot if that's what you are worried about.
However, if there are lots and lots of classes for each element, then you have to realize that you are using valuable bandwidth and increasing the time it takes to load the entire page that way. You can avoid that problem by externalizing the CSS so that the browser can cache it.
Are you using jquery to query the elements that you really want to modify? It might turn out that its more easy to pick those elements with jquery selectors which seem difficult or impossible with standard JavaScript and thus you can possibly avoid all these extra unnecessary classes.
Bottom line, there is no problem in using lots of classes if they are needed, and that's perfectly fine for production, but if you don't need them, like in your case, there has to be a better solution that you can possibly come up with.
Just for a data point, I took a look at GMail's HTML yesterday (their buttons are very nice) and it's full of that kind of thing.
Here's an example:
class="goog-imageless-button goog-inline-block goog-imageless-button-collapse-left goog-imageless-button-collapse-right"
Classes are not just for CSS, they're for the categorization of sections of markup. Applying styling based on that categorization is just one use. So if the classes are useful for other categorization purposes then that is fine, and perfectly good practice.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
Hey. We're building a large ASP.NET website, and have hired an external firm to do the design (CSS + protoype pages). In fitting the design to the page, we've found a number of problems that indicate ASP.NET's workings were never considered. My question is - Is there a common standard (that should be) used by design firms creating what will become an ASP.NET site?
We've found things like:
Using IDs on HTML elements for
CSS/JS to find, which doesn't work
with server tags generating IDs.
IDs with hyphens in them
ValidatorSummary example built in a completely different style to ASP.NET's.
Assumptions that all buttons will be <input> tags
Margin styles on <div>s, interfering with our use of panels
The first instance is a problem. The rest are inconvient misunderstandings. As usual, there are intense time constraints, so in this sea of 'we'll fix it / get our designer to look at it / work around it', I'm largely hoping there's some fundamental building block that would have stopped most of these problems from happening.
The design firm is large, with a substantial body of large-site work behind them, so sadly the 'don't hire a one man shop' wisdom isn't the ticket in this case...
[Update]
If you're in the position of hiring an external web design firm, and have the luxury of early collaboration and wish to help bridge the gap of meeting ASP.NET's requirements, here's our current list of guidelines. Please comment below if you feel there's something that should be added:
Please encapsulate each the page in a <form> tag (ie.
place it directly after the
<body> tag), and use no other <form> tags on the page
To
display a summary of page validation
errors, please cater to rendering
the following format example:
<div class="error_class">
<h3>Please review the following fields</h3>
<ul>
<li>Home phone number</li>
<li>Surname</li>
</ul>
</div>
Please avoid driving styles off the ID or name property.
If there are HTML components that need to be turned on and off, these components should be encapsulated in a <div> element, so that the div's visibility can be set to 'false'.
If styling buttons, please cater to both <input> tags and <a ... class="example_class"> <span>Button text</span>` formats.
Avoid setting attributes on class-less <div> and <span> tags.
Thank you for bearing with us.
Most design firms I have worked with required some hand holding on what they can and cannot do with regards to designing for an ASP.Net app. You hit all the big ones, the ID thing being the biggest issue.
In terms of building blocks, collaboration early and often did the trick for us. Once we established how we needed the design to be implemented to work easily within an ASP.Net context, things went smooth. Of course, the better the designer on the other end, the easier its going to be.
I am not one for having developers chop up PSD files. With the right designer or firm, you should be able to save time and money and get it done right from the outset. Most developers I know can tweak and extend css and markup, but are much less efficient when starting from a PSD, or from scratch.
HTH.
Any time I've worked with design firms building asp.net pages I've always just had them design what it should look like. Nothing to do with the markup or css. This leaves a lot of work to be done by the developers, but avoids all the mistakes you just mentioned. I've always had designers deliver a PSD file and chopped it up myself.
If this doesn't suit your needs you can always try ASP.NET MVC. It gives you a lot more control over the markup you put on the page.
In general, people who make their living as designers do not know ASP.Net well enough to avoid it's, ahem, quirks. It's not reasonable to expect them to produce HTML and CSS which take ASP.Net's rules into consideration. The standards are actually on the designers side in this one.
For future integration, you may want to go with a firm that has their own .Net devs who work with their designers or, if you have the option of .Net 3.5, you could work with a design shop that has MS Expressions Web at their disposal.
Looking for some direction here as I'm running into some migration problems.
We have a legacy application. The 'infrastructure' is running just fine. Business logic and data access layers written in VB calling SQL Server for the database.
I have a LOT of experience writing Winforms (desktop) application and have had no problems. However, the last time I wrote any ASP.NET stuff was in 1.1 (VS.NET 2003).
Among other things, for ASP.NET 2.0 and up, the Grid layout is gone. It's not just a simple case of dropping controls on a form, aligning them, ordering them and working with the code-behind anymore.
The new web-based application is starting out pretty simple. Just a common header (already made a user control for that) and footer with your typical CRUD functions in the middle.
I tried being 'intuative' in using a master page with content place holders but I couldn't get the placeholders to "grow", to say nothing of not being able to put a text box where I wanted one. Oh, I found the option in VS2008 to allow absolute positioning but it only worked for SOME controls - others I had to manually edit the asp tags.
Then I saw examples using div's and tried to implement them but I ended up with results that had objects writing on top of each other. The online help wasn't helpful to say the least.
Does anyone know of a good book, website or tutorial that can give the basics of what I'm looking for? In practice, I'm looking to make simple pages where some objects may have to push others gurther down the y-axis (as in, several comments being made and that section would push the section listing the 'attachments' down further). I have no trouble when it comes to all the other aspects of this application. It just appears that my webforms skills are about 3-4 years out of date.
This isn't going to be some fancy flash/silverlight application - just simple 'data maintenance' to get rid of some ugly and bug-prone processes involving reading common mailboxes and decoding Word files. The new goal is to have a nice weborm with proper validation.
I guess what I'm looking for is a "Webforms for Winforms programmers" book or site.
Help!
Thanks in advance.
The best advice I've heard on learning to use html/css layout goes something like this:
When building a new page, don't try to get all fancy up front. Start by building a very basic, text-only page. It should look like something from 1996- that brief period where everyone had just discovered the web but had not yet started using the table tag for layout- only no comic sans font. Don't use images at this point, unless the image is genuinely a part of the information being conveyed (as opposed to the window dressing to make it look pretty: you can add those later). There will likely be an h1 at the top of the page, and give each sub heading an appropriate hN, but at this point there shouldn't be any layout information in the page at all. The only place you'll have a table tag is if you genuinely have tabular data to show. If it helps you write this code then you can wrap everything in old-fashioned <center> tags for now- just don't forget to remove them later.
Now let's start tweaking the markup a little. Use things like ul (unordered list) for your list of navigation links and label/legend to identify and group your form areas. The general idea here is to have each element on the page encased in the most appropriate html tag, and to use the full set of available tags- each for it's designated purpose.
At this point you have a page that is ideally suited for a screen reader or search engine. By building this page first, you have made SEO and accessibility compliance easy on yourself. Of course those aren't the only requirements, so we're not done yet.
Now you need to identify the different sections of your page, from both the layout and logical perspectives. The page should largely already be divided logically, but you may find a few places where the normal tags don't cut it. You'll also want to group certain elements for layout reasons. Encase each of these areas with a div tag, and give the tag a class name that refers to the purpose for the tag: the group your are creating. This is just another case of using the a tag (the "division" tag) for it's intended purpose. Also, since elements can have more than one class, you may want to think about also grouping your classes logically. For example, you might want to have a separate class that distinguishes the site template from the rest of the page.
By and large this should not have changed the appearance of the page, but now you have something where it should be very easy to start adding styles. At this point you can now start adding images and layout. The goal here, though, is to change the actual markup as little as possible. If you can manage it only add ids and classes, though you will likely need to add an additional span or div that you had not identified earlier, and sometimes you'll need an extra block level element to force a compatible layout across browsers.
If things are done correctly, the result is a page that not only looks good, but is also easier to work with when testing across browsers, will naturally degrade well when a style or javascript feature isn't supported, and scores well for SEO and accessibility. This also makes it easier to have a developer build a simple page that provides a certain level of functionality, which they can this pass off to a separate designer to make it look good.
You may also want to check out A List Apart. This is a great website with lots of "tricks" for using CSS to layout things on the web along with lots of other web oriented content.
Grid positioning was an abomination for websites. Sure it made for an easy transition from those familiar with the WinForms designer, but it produced horride HTML that is nearly impossible to maintain.
The very best resource I can recommend to you is CSS Mastery. You'll need to learn HTML and CSS, but they're quite easy to get into.
By the sounds of it, you're looking for a crash course in HTML ?
the "Design Canvas" of an ASP.NET aspx Page & ascx Control is just HTML tag markup.
If you've no web design experience, I'd recommend starting somewhere like
W3Schools
When Microsoft gave us ASP.NET, they tried to make programming websites, more like programming rich client applications. However, there are a lot of issues you have to deal with, the major one being statelessness, when developing for the web that don't exist when developing a thick client app (WinForms). So the first step is to not think of the two as similar in anyway.
The drag and drop tools are nice, but what you really need to understand is HTML and client server models. HTML will help you understand how things are getting laid out, and client server models are important to understand how data gets to and from the web to the server. If you have developed in ASP.NET 1.1, then things really haven't changed for 2.0. The concepts are the same, just some of the provided controls have changed.
A lot of people were really unhappy with the grid-based layout from 1.1, because it didn't really work in a number of situations. It still has to ultimately render as html, and html just isn't suited to that kind of layout. For example, things might not be ordered properly or pushed off the screen for mobile browsers (iPhone, etc). There's also things like screen readers for the blind. If you work for the government, that 2nd item is a legal requirement rather than just a nice-to-have, and there are a lot of developers who do work for the government.
So ASP.Net 2.0 tried to generate markup that's at least a little nicer for html. The downside is that you actually have to understand html layout now. But, c'mon: you're building a web site. If you can't handle a little html you're in real trouble.
My advice to build one static page using something other than visual studio. Use <input tags rather than server controls on that page and don't actually implement any logic. Use it to understand how your layout will need to work. Once you have that down, it's really easy to duplicate that for your pages in Visual Studio.
This doesn't really belong as a separate answer, but I wasn't sure you were likely to see another comment to my response above.
The normal behavior of all block-level elements, including divs, is for each new element to appear below the previous element. It sounds like you've set position:absolute; on everything, perhaps while playing with the Grid-based layout option in visual studio. Don't do that- it's hijacked the expected behavior and that's why you see everything piled on top of each other.