intTypePromotion=1
zunia.vn Tuyển sinh 2024 dành cho Gen-Z zunia.vn zunia.vn
ADSENSE
 » 
 » 

Web Programming with HTML, XHTML, and CSS Second Edition- P9

Chia sẻ: Thanh Cong | Ngày: | Loại File: PDF | Số trang:50

Thêm vào BST
Báo xấu
143
lượt xem 54
download
 
  Download Vui lòng tải xuống để xem tài liệu đầy đủ

Web Programming with HTML, XHTML, and CSS Second Edition- P9: Điều này bắt đầu hướng dẫn nhận xét HTML và cũng giới thiệu đến bạn bằng cách sử dụng XHTML cho cấu trúc của một trang web và cascading style sheets (CSS) để kiểm soát như thế nào một tài liệu sẽ xuất hiện trên một trang web. Bạn se tìm hiểu làm thế nào để tận dụng lợi thế của các tính năng mới của các trình duyệt trong khi đảm bảo rằng các trang của bạn vẫn làm việc ở cũ, nhưng phổ biến, các trình duyệt. Bằng...

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Web Programming with HTML, XHTML, and CSS Second Edition- P9

  1. Chapter 10: Design Issues While using images often makes a menu very distinct from content, you must be careful that your images are not so large that they slow down the loading of the site. Figure 10-6 shows an example of using images for navigation within a separate box. Figure 10-6 You should take a closer look at how this menu was created; the menu is created inside a element; and the CSS rules for that element specify that it should have a background image that repeats from left to right. That background only needs to be 1 pixel wide, making the image smaller, and therefore saving the amount of time that a page takes to load. The background image is also the same height as the images that are used to click on. Inside this element are the images that link to the other pages. When you come to look at the CSS for this example in a moment, note how there is a rule in there that specifies that images within a link should have no border — this is because IE will, by default, add a blue box around such images. Between each image is a spacer image that is a darker line to separate the links if they are butted up next to each other. Here is the XHTML for this example (ch10_eg06.html): The Used Equipment Exchange
  2. Chapter 10: Design Issues And here is the CSS for this example (ch10_eg06.html): body { background-color:#ffffff; font-family:arial, verdana, sans-serif; font-size:12px;} .page {width:700px;} .navigation { background-image:url(images/backdrop.gif); background-repeat:repeat-x;} a img {border:none;} Because all these images are fairly small (and they were saved for the Web using the Save for Web option in Adobe Photoshop), they should not add too much time when downloading the page. If You Use Icons to Represent a Link, Make Sure Everyone Will Understand Them Many web sites use images known as icons for links. These icons are images such as a magnifying glass to indicate a search feature. If you are going to use icons, make sure your target audience will understand these images or users will not click them. Many users are familiar with the following icons: ❑ A house to indicate the home page ❑ A magnifying glass to indicate a search feature ❑ An envelope to indicate an e-mail address or link ❑ A question mark to indicate help files If you use icons that are less common, it’s a good idea to add the link in words as well as using the image. (Don’t expect that users will hover over a link to find a tooltip that tells them more about that link.) Menus Must Be Quick and Easy to Read As I have already mentioned, when browsing web pages, most visitors do not really read them — they scan them. Making your menu distinct from the main part of a page (and using bold, a different color, or underlined text for links within the body of a page) will help users scan and register the navigation items more easily. Any words or images you use in a menu must be large enough to read (especially for users who have high screen resolutions that make text appear smaller), and text must contrast well with its background. 372
  3. Chapter 10: Design Issues Links should also be short and concise. For example, a link that just reads “Home” is a lot more obvious and easier to read and understand than a link that says “Front door.” Having said that, a couple of simple words are always better than one word of jargon. Grouping of Menu Items Must Be Logical If you have a lot of pages, you might well decide to create submenus. If so, it’s very important that you group menu items so that visitors will understand where to look for something without having to search through several sections or categories. If you do use submenus, you should make sure that they are clearly distinguishable from the main menu, and that it is clear which items belong to which section. Submenus often make use of a different colored background, smaller font, an indented position, or an alternate color to show they are distinct from the main menu. For example, if you are creating a site for a computer store, you might create a grouping something like this with three main sections, each containing its own subsections: ❑ Computers: Desktop computers, laptop computers ❑ Software: Business software, games ❑ Peripherals: Printers, scanners This would be easier to navigate than an alphabetized menu of all sections. Menus Items Must Be Easy to Select If a menu item is too small or there is not enough space between menu items, it can be very difficult for some users to select the correct menu item. A user with a dodgy mouse, poor eyesight, or difficulties with motor control may have trouble hitting a small or tight target, and even those most able to control a point- ing device will find it easier to hit larger targets. Furthermore, most users can find moving targets either irritating or hard to hit — and they are best avoided in most designs. When you are creating a menu, you need to make sure it will work on all the main browsers. As the Web has grown up, there have been many menus (particularly drop-down menus that use JavaScript) that do not work even on some of the more common browsers. There are two ways around this problem: ❑ Test your menu on many different types of browsers (particularly older versions). ❑ Avoid complex code in menus. Drop-down or pop-up menus, which make new items appear as you hover your mouse over a heading, tend to be particularly problematic for two reasons: ❑ They are often written in JavaScript, which is implemented slightly differently in the various browsers — particularly the older ones. So while a menu might appear to work fine in the designer’s browser, some other visitors will simply not be able to navigate the site. ❑ They can be too sensitive or move too quickly for users to select the item they require. 373
  4. Chapter 10: Design Issues Over the years, I have come across many sites that have attempted to implement drop-down menus that simply do not work in my browser. As a result, and for usability reasons, I now avoid these menus completely. Some designers play with more experimental types of menu (particularly in Flash) that often require quite dexterous control — these menus often move and slide between items as the user moves the mouse to the left or right when hovering over an item. While such menus that require fine control of a pointing device often look great on experimental sites, they can exclude those who do not have excellent control over their pointing device, and are therefore best left to the realms of more experimental sites than regular business sites. Menus Must Load Quickly When creating a menu you should not expect that every visitor to your site has a fast Internet connection — some visitors may still be on dial-up connections or in an office building with a lot of users on the same con- nection. Although connection speeds are constantly improving, your menu should load within the first cou- ple of seconds. If your menu takes longer than around eight seconds to load, many users will think that the page is not loading or that the browser has frozen — they will try to reload the page or, even worse, click their Back button or go to another page. The loading speed is particularly important for designers who use graphics or Flash in their menus (plain text loads very quickly). If you want an image to change when the user rolls his mouse over an image to make it appear highlighted, then your loading time can double (as a second image is required for each image that the user rolls over). Note that some browsers require the content of a table to load completely before displaying the table, so if you are putting images in a table, users might have to wait quite a while for a page to load. Menus Must Be Consistent Across a Site The more pages a site contains, the more navigation items you are going to require. As soon as you have to introduce submenus, the navigation becomes more complicated and will vary from page to page. It is very important that the primary navigation remains consistent across all pages. The submenus in each section of your site should be in the same position on each page and have a similar look and feel, so that users know exactly where to go to navigate the site. Links In addition to the menus your visitors will be using to navigate the site, many web pages contain other hyperlinks in the text that makes up the body of the document. This short section addresses two topics regarding links that are not part of the main menu: ❑ Text links ❑ Images as links 374
  5. Chapter 10: Design Issues Text Links By default, text links tend to be blue and underlined. Some experts on usability suggest that all links should be left to their default appearance. However, from your experience of the Web, you probably know that using a color that’s clearly different from the main text makes it easy to tell what text makes up a link. As you saw in Chapter 7, you can change the appearance of links as a user hovers over them and when a user has already visited them. Here is a quick reminder of how you change the appearance of links using CSS (ch10_eg07.css): a {font-weight:bold; color:#ff0000; text-decoration:none;} a:hover {color:#FF9900; text-decoration:underline; background-color:#f9f0f0;} a:visited {color:#990000;} As users hover over links, these links will be underlined, change color, and gain a background color. The visited links will be in a different shade reminding users where they have been. You can see this best if you run the example available with the download code for the chapter. It is generally a bad idea to use a different weight of text when a user hovers over a link because this changes the width of the font, making it hard to read and changing the width of the line. Images as Links Images are often used as links in menus, advertisements, photos to click on, graphical icons, and so on. Whenever you use an image as a link you should use two attributes on the image: ❑ alt =”description of image or text on image”: Use this to tell users who cannot see the image what the image is of or what it says. ❑ title=”where the link will take the user”: Use this to show users a tooltip that says where the link will take them; this is also used by screen readers. If you do not use CSS to control the border of images that are links (and set them to “no border”), you should also add the border attribute: ❑ border=”0”: If you don’t use CSS to control borders or this attribute you will get a border around the image in many browsers, which can look unsightly. You saw an example of using images as links earlier in the chapter (ch10_eg06.html). In Chapter 12, you’ll see an example of using JavaScript to create what are known as rollover images, or images that change as the user hovers over them. Site Search Features The third way a user can navigate your site is by using a search feature. A search feature allows users to immediately look for a keyword (or words) that relate to the information they are trying to find from your 375
  6. Chapter 10: Design Issues site. Searching can save users from having to learn your scheme for navigating the site and offers another way to find the information if they are having difficulty finding what they came for. Search Features Make Sites More Usable Search features are increasingly important as your sites grow. If you have only a few pages then your menu should be rather easy to understand anyway. However, larger sites, which may incorporate sub- menus where not all options are featured on every page, can really benefit from this addition. There are many ways in which you can implement a search feature on your site. While some methods require fairly advanced programming experience, there are ways in which you can add a fairly simple search feature. Large commercial sites, where the content is stored in a database, can use programming commands called queries to ask the database which pages contain the terms a user searched for, or they can use a special indexing application to index the site and make the search facilities available. For sites that do not use databases or indexing tools, the easiest way to add a search feature to your site is to use a third-party search utility to index your site for you. These services also give you the code to create a search box that will send queries to the service’s site. When visitors to your site use a search box, their query gets sent to the server of the company offering the search service, and the server will then return the answers to the user on your behalf. The best-known company to offer this kind of service is Google, which does it for free at the time of this writing. (Google makes its revenue from supplying ads with the search results — but as you can see from Figure 10-7, these are not intrusive; they appear only on the right side of the results page, as they do when you send a query to Google.com.) Adding a Google Search to Your Site Google, which is currently the most widely used search engine on the Internet, offers a very powerful and flexible service whereby you can use its search engine to provide a search feature on your own site. At the time of this writing you have to register in order to use the service. However, the instructions and setup on the site are quite simple and the service is free. Figure 10-7 shows you how an arts and music site called Neumu.net has a small search box underneath the navigation bar. When a visitor to this site searches the Neumu site, the request is sent to Google, which then generates a page with items from Neumu containing those words and sends it to the user. Obviously, the results point back to the Neumu site, as you can see in Figure 10-8. You can see the code for the search box by selecting View Source on the menu. 376
  7. Chapter 10: Design Issues Remember that you cannot just copy this code; you need to register for the service yourself. Another site that offers a free search service for a limited number of pages is www.Atomz.com, but it does charge for larger sites. Figure 10-7 377
  8. Chapter 10: Design Issues Figure 10-8 Shading Multiple Rows of a Table When dealing with tables that contain multiple rows of information, you can make it easier for visitors to follow the rows of the tables if you alternate the background color of the rows very slightly. Figure 10-9 shows you an example of a table that has alternating colors for each row. This was achieved using odd and even classes on rows like so (ch10_eg08.html): Item Description Cost 378
  9. Chapter 10: Design Issues Subtotal Imation CD-R 25pk Blank CDs 25pk 700mb data and audio 16.99 16.99 Biro Bic biro black .25 17.24 Envelopes 25 pack DL size brown 2.50 19.74 Figure 10-9 Here is the CSS that goes with this example: body{ color:#000000; background-color:#ffffff; font-family:arial, verdana, sans-serif; font-size:12pt;} th {font-weight:bold; text-align:left; background-color:#fff336;} .odd {background-color:#d6d6d6;} .even {background-color:#ffffff;} Remember that whatever background colors you use, there must be a good contrast between the back- ground and the text in order for the user to be able to read it easily. The very light gray in this example is a good example of a color that does not dramatically affect the readability of the table itself. 379
  10. Chapter 10: Design Issues Forms I have yet to meet anyone who enjoys filling in forms — especially on the Web. Therefore, if your site must include a form, good design is essential or people will not fill it in (and if you are an online shop that is an essential part of your core business). In this section you are going to learn about the following: ❑ What to do before designing the form ❑ How to design a form, select the right form controls, group them correctly, and label them ❑ How best to lay out a form To work through the points in this section, you will see an example of a basic form that users have to fill in before they can register for an online service. Before Designing the Form Before you address how a form should really look, you need to do some preparation — this is just like the preparation you need to do before you start designing a site, although it should take less time. Listing Required Information First When designing a form, you should start out by creating a complete list of the information you require from a user. You might start with a general list with items such as login details, name, mailing address, and e-mail address, but you need to make sure for each item that you know what makes up these require- ments. For example, do you need to get a user’s first name and last name separately? If so these will have to be separate items on the form. What makes up the address: house number/name, street name, suburb, ZIP Code, and so on? Which ones need to be separated from the others? Here is a list of the information that is needed for our registration form: ❑ Login information ❑ User’s name ❑ User’s address ❑ User’s contact details When this is broken down, the exact information that’s needed is as follows: ❑ Login information: Username and password ❑ Name: First name, last name ❑ Land address: Street address, city ZIP Code ❑ Contact information: E-mail address, area code, phone number When you are creating forms, you should ask only for the information you really need to get a job done. It’s very tempting when gathering information from visitors to ask as many questions as you can; but the longer a form is, the less likely it is that users will complete it. 380
  11. Chapter 10: Design Issues If you want to collect lots of nonessential information (for example, to get a better idea of the demographic of visitors to your site), consider offering users an incentive to participate and answer the questions after they have registered/purchased an item, such as an entry into a prize draw. Note that when collecting and storing information about customers, you must also ensure that you meet the data protection laws of your country. Group-Related Information Once you know what information you want to collect from a visitor to your site, you need to look to see if there is a logical grouping to the information you require from visitors to help them understand the form. If you find such a grouping in related information, you should make sure that these items go together in the form. In the example for this section you need three groups of information: ❑ Name and e-mail address ❑ Login details ❑ Other contact details In this example, the grouping is the same as the initial list of required information before it was broken down, but sometimes the grouping can be quite different. Model Paper Forms Users Are Familiar With If you are creating an online application that represents a form that would previously have been filled in on paper and that your users would be familiar with, then you should make sure that your online form reflects that paper form. (Note that if the form would not have been familiar to users this is not necessary.) If the goal of your application is to put existing software online, then it could also be modeled on the software. The reason for modeling your form on something the user is familiar with is quite obvious; it makes it easier for the user to fill in. That is not to say that the layout of the form should be exactly the same (often paper forms cram too many questions into a small space). Rather, you should be asking similar questions in a similar order and grouping. Are Users Going to Provide the Same Information Each Time? Will users have to provide the same information each time they visit the site? Or will some data be stored in a database (or other application) and retrieved when they log in again? For example, if you are working on an online store, once the user has logged in, will the application remember the user’s name, address, and contact details? If you are going to store information about users — in particular their credit card details — you must make sure you are abiding by your country’s laws on storage of such information. You should also consider how your form is going to be processed. If it’s going to be processed by a human, the human can interpret the data the user enters, whereas if it goes straight into a database, users must be a lot more precise about the information they enter. This may affect your choice of form control required to collect the information. 381
  12. Chapter 10: Design Issues What Else Needs to Appear on the Form? Several forms contain extra information, such as shipping information, price lists, legal notices, and so on. Before you start designing the form you should be aware of all the information that might be put on it, not just the form controls themselves. Designing the Form Now that you know what information must be captured by the form, you can design it. You can start by selecting the appropriate type of control and then grouping the controls together and labeling them. You can then add final touches to the layout of the form to control its presentation. Selecting the Type of Form Control You learned in Chapter 5 about the different types of form controls that you can use. It’s important that you choose the correct type of form control for the information that you are trying to collect. Once you have decided on which form control to use for each piece of information you’ll have an idea of the possible length and layout of the form. Entering text: ❑ If there is just one line of text, you use an element whose type attribute has the value of text. ❑ If you want the user to enter more than one line of text you use the element. ❑ If the information is sensitive (such as a credit card or password) use an element whose type attribute has a value of password. Giving the user a limited choice of options: ❑ If the user can select only one option (from several), use a group of radio buttons (with the same name) or a drop-down select box. ❑ If the user can select multiple items, use checkboxes or a multiple select box. Also consider how visitors would be used to giving this kind of information. For example, use a set of text inputs for each line of an address rather than, say, using a combination of a text input for the street name and a select box to indicate whether the street is a street, road, or avenue for the first line of the address. Remember that each form control should use a name that describes its content. Rather than just arbitrary names such as input1 and input2, you will often see form control names that are given a prefix to describe what kind of form control they relate to: ❑ txtName for text boxes and text areas ❑ radName for radio buttons ❑ chkName for checkboxes ❑ selName for select boxes 382
  13. Chapter 10: Design Issues Radio Buttons and Checkboxes Although radio buttons and checkboxes take up more room than select boxes, they tend to be easier for visitors to use because users can see all the options at once (as long as the list of options is not too long, such as a list of all the countries in the world, in which case you might use a drop down select box instead). If there are only three or four options, and the user is allowed to pick only one, then radio buttons are usually a better choice than select boxes because all are visible. An exception to this rule would be if the design contained several select boxes (in which case the consistency of design is more important). If there are only three or four options, and the user is allowed to pick several, then the use of checkboxes for multiple selections is usually better than a multiple select box no matter how much space they take — not only because checkboxes are more common, but also because if you use a multiple select box you should generally tell the user that they can select multiple items and how to go about this. Checkboxes are also ideal if users have to indicate that they agree to or have read something, such as terms and conditions. It’s important to use a checkbox in these cases rather than a radio button. When you have selected a radio button you can change your choice to a different radio button, but there is no way to deselect all the radio buttons in a group (whereas you can click on the same checkbox to clear it). You should never use a programming language (such as JavaScript) to change the intention of radio buttons or checkboxes. In other words, you should never make checkboxes mutually exclusive (as radio buttons are), and you should not allow a user to select more than one radio button from a group because this will confuse users who expect radio buttons and checkboxes to follow their normal default behavior. Also, be careful not to repeatedly mix radio buttons and checkboxes in the same form or you will confuse users. Radio buttons and checkboxes also allow you to provide more information to the user than a select box. A radio button or checkbox can have a long description next to it, whereas if you use a long description in a select box the whole box grows wider. You can see an example of a long drop-down (which goes off the screen) and a set of radio buttons in Figure 10-10 (ch10_eg09.html). If your radio buttons represent an optional question, you should not automatically select one item by default. You cannot deselect all radio buttons by clicking them again as you can checkboxes; you can make only a different choice. It is also often helpful to give users an “other” option if they might not choose one of the options you have given. Figure 10-10 383
  14. Chapter 10: Design Issues Select Boxes Select boxes, also known as drop-down list boxes, save space on the screen, especially when there are lots of options, although as Figure 10-10 showed they do not look very good with long descriptions for each option. Indeed, the width of a select box is the width of the widest option in it. You should remember when providing a select box to include options for all users. For example, if you use a drop-down for U.S. states and you have visitors from outside the U.S., you should have at least one option for those who do not live in a U.S. state, even if the option is just “Outside U.S.” The order of items in a select box should reflect users’ experience; for example, if you use month names, put them in chronological order, whereas if you use states or countries, alphabetical lists are easier to use. If one (or a few options) within a long list are more popular or more likely to be chosen than other options, then you should put these at the top of the select box so that the user comes to them first. Text Boxes Text boxes tend to be the most natural way for users to offer the majority of information. Generally speak- ing, text areas should be large enough for users to enter what they want without having scrollbars appear- ing (unless they are very long, such as the body of an e-mail or an article for a web site). Be aware that users often take the size of the text box to be an indication of the length of text that they should provide. This can be especially helpful for things such as dates, as you can see in Figure 10-11, where you want the user to enter four digits for a year. Figure 10-11 Grouping Controls Once you’ve decided what form controls you’re going to use, you can start to put them on the page. As I already mentioned, these should be grouped together into related items of information — and these groups should reflect the users’ understanding of the topic. You can group form elements in the following ways: ❑ Fieldsets ❑ Labels ❑ Splitting the form into several pages You can also use padding and shading as you saw in the first section of this chapter, which covered white space. 384
  15. Chapter 10: Design Issues Using Elements You already learned about the element in Chapter 5. It allows you to group sections of a form between the opening and closing tags. The form can also carry a element to indicate a caption for the box. For example, here is a form for a user to enter their login details (ch10_eg11.html): Login User name: Password: Confirm password: Fieldsets were introduced in IE4 and Netscape 6. Older browsers just ignore the and buttons if they do not understand them, so you can safely add these elements to all forms. You can see what this example looks like in Figure 10-12. Figure 10-12 You may also choose to use an alternative to fieldsets to group together parts of a form, such as line breaks, background colors, or a table with associated style rules, but fieldsets have specifically been introduced for grouping form elements, and you can associate styles with the element, as was done in this example (ch10_eg11.css): fieldset { width:250px; padding:10px; font-size:12px; text-align:right;} Note here how the width property has been set in the style sheet. This is particularly helpful to add to elements because they will otherwise stretch to the width of the browser window (or con- taining element). 385
  16. Chapter 10: Design Issues Splitting a Form into Separate Pages Long forms not only put off users but also make the form harder for the user to fill in. And if you are writing validation and error handling (such as the error messages to say a form field has not been filled in or contains the wrong sort of information), then this code becomes more complicated as a form gets longer. Therefore, if you have a long form you can split it up into several pages. The reasons you might do this include: ❑ Smaller forms are less intimidating. ❑ When related information is put on the same page, it is easier to digest. As a general guide, your form should be not much more than a “screenful” (at 1024 × 768 resolution) so the user does not have to scroll much. If you split a form into separate pages you should clearly indicate to the users how far they are through the form. You can see, in Figure 10-13, a form that has been split up into four pages and a confirmation page. Splitting a form into several pages can introduce new complexities into the programming because the program has to remember what a user has entered between each form; however, there are several ways of doing this with a little extra effort. You will generally want users to go through these steps in order rather than allowing them to go between pages at random, so avoid links that allow them to jump to any page. Figure 10-13 386
  17. Chapter 10: Design Issues Number Questions If you have a lot of questions, as in an application form or an online test, you should number questions so that the users know where questions start and end. This can also be a help if you want to indicate to a user that he or she should jump to another section of the form because you can explicitly indicate which number question they should be going to. Layout of Forms Ideally, a layout of a form should reflect what a user would expect to see when dealing with such data. Layout is related to the user’s experiences with paper forms or software equivalents. You can even con- sider an everyday experience such as how a user writes out his or her address. (We usually write our address on a few separate lines as opposed to using drop-down boxes.) Labeling Controls The first issue concerned with layout of forms is the labeling of controls. It’s very important that each control is clearly labeled so that users know what information they should be adding and where. There are two types of labels: ❑ Implicit labels that are normal text and markup next to the control ❑ Explicit labels that use the element You should consider the following as guidelines for where the label for an element should generally appear: ❑ Text entry fields: To the left of the input or directly above ❑ Checkboxes and radio buttons: To the right of the checkbox or radio button ❑ Buttons: On the button itself — its value Implicit controls are the simplest way to label a control. To add an implicit label, you simply add text directly next to the label in question. For example (ch10_eg12.html): First name: Last name: E-mail address: The disadvantage with this approach is that the presentation is not very attractive — and gets worse with longer forms — because the form controls are not aligned well with each other, as you can see in Figure 10-14. While elements do require a little extra programming effort, it is generally a good idea to get into the habit of using them. You may remember from Chapter 5 that the element must either contain the form control or use the for attribute whose value is the value of the id attribute on the form control: First name: Last name: 387
  18. Chapter 10: Design Issues E-mail address: Figure 10-14 Unfortunately, this will look just the same as the previous example shown in Figure 10-14, but the element does have advantages: ❑ It makes it easier for screen readers to associate a control with its label. In particular, you can associate labels with form controls even when the label is not next to that item — for example, in a table the label might be in a row above the form control. ❑ Labels can increase the clickable area of a radio button or checkbox, which some users find hard to accurately click on because the user can click on the label. Labels were first supported only in IE4 and Netscape 6 and later versions; however, older browsers just ignore the element and display their contents, so you are safe to use them on any form. Here you can see the example of a form that allows you to indicate how you heard about a company. When the users click the label, the radio button associated with that form will be selected (ch10_eg13.html): How did you hear about us? Word of Mouth Google Search Magazine Ad Other   You can see this form in Figure 10-15. 388
  19. Chapter 10: Design Issues Figure 10-15 Remember that when choosing the prompt or the label for a form, you must choose words that will really mean something to users. What might be obvious to you might not be so clear to a visitor who is not as familiar with the topic as you — for example, a productId number might be a unique identifying number for a product, but a customer can’t be expected to know this or where to find it. Using Tables for Layout Many designers and programmers use tables to lay out and position form elements on their web pages. However, you must remember how tables linearize in a screen reader (as discussed in Chapter 4). To remind you how a screen reader would linearize a simple table, look at the following table. Row 1 Column1 Row 1 Column 2 Row 2 Column 1 Row 2 Column 2 Row 3 Column 1 Row 3 Column 3 The cells of this table would generally be read row by row in the following order: Row 1 Column 1, Row 1 Column 2, Row 2 Column 1, Row 2 Column 2, Row 3 Column 1, Row 3 Column 2. So, the correct way to lay out the previous example in a table would be as shown here (ch10_eg14.html). Note that this example does not use the element so that you can understand the order in which elements are read without the use of this element: First name: Last name: 389
  20. Chapter 10: Design Issues E-mail address: This will order the elements correctly, and users with a screen reader will understand the form. Note that the class=”formPrompt” on the elements that are labels is associated with a CSS style sheet rule that indicates the text should be right-aligned in the table. This makes for a much neater display on the pages and prevents large gaps between a label and its associated control. You can see the result in Figure 10-16. Figure 10-16 Tables that get more complex than this need a lot of consideration. For example, take a look at Figure 10-17. Figure 10-17 Here there are two columns of form controls and the labels are above the elements. This design would necessitate the use of the element; otherwise a screen reader would read the labels on the first row and then the two form controls on the second (ch10_eg15.html): First name: Last name: 390
ADSENSE

CÓ THỂ BẠN MUỐN DOWNLOAD

THÔNG TIN
TRỢ GIÚP
HỖ TRỢ KHÁCH HÀNG
Theo dõi chúng tôi

Chịu trách nhiệm nội dung:

Nguyễn Công Hà - Giám đốc Công ty TNHH TÀI LIỆU TRỰC TUYẾN VI NA

LIÊN HỆ

Địa chỉ: P402, 54A Nơ Trang Long, Phường 14, Q.Bình Thạnh, TP.HCM

Hotline: 093 303 0098

Email: support@tailieu.vn

Giấy phép Mạng Xã Hội số: 670/GP-BTTTT cấp ngày 30/11/2015 Copyright © 2022-2032 TaiLieu.VN. All rights reserved.

 

Đồng bộ tài khoản
2=>2