Website Affinity Assessment

Part 1: Background and preparation

Roger Johansson of this "evaluating website Accessibility" trilogy, written is quite practical, for the Web site affinity is very suitable for the introduction. At the end of this article, there is a slight deletion. Special thanks to hlb and othree , hehe, this article thanks to them.

Around the world, more and more countries are starting to ask governments and public service websites to be standards-based and to follow affinity guidelines. This also allows people involved in building and maintaining such sites to have the ability to build/evaluate affinity websites.

Many people, whether web developers or webmasters, are new to the site's affinity, and they find it difficult to assess. The three articles in this series aim to make it easy for the unprofessional to do some basic affinity checks. I hope it will be helpful to everyone, at least make some sites more full of affinity.

This series includes the following articles:

site Affinity Assessment Part 1: Background and preparation ( this is the article) will provide us with some relevant background and introduce some useful evaluation tools.
the website affinity assessment Part2: Routine Check will explain some of the affinity problems that can be detected by some automated tools or relatively simple manual methods.
Web site Affinity Assessment Part3: Digging deeper explores problems that are difficult to detect with automated tools that require manual methods to evaluate and require more time or experience.
Note that the detection methods described in this series do not involve people with disabilities who actually use the screen reader and other assistive devices. However, if you do not intend to do so, as long as you have completed the test described in the article, you will have a very clear understanding of the status of the site to assess the affinity.

Background
Web affinity is generally defined as: the Web for Everyone is an affinity (accessible), regardless of disability or not. This definition implies that affinity is for disabled friends. This is not an official definition of affinity (1), but whether or not it comes from the crown, I think the scope of this definition is too narrow, and not only I think so. For example, Robert Nyman in the What is accessibility? has also been discussed in this issue.

The affinity I mentioned in this article (and elsewhere) is a much broader affinity, which also includes device independence (Device independence)-regardless of user disability, user agent, or platform condition, are free to connect (universal access). For anyone, the WEB should wait to be an affinity.

Just look at the multitude of public service websites in Sweden (and most other countries in the world) and find a depressing phenomenon. Developers who build these sites do not make sure that their sites are web-based, or that they are approachable. Even the most recent sites for refactoring are the same. If you don't understand, you can pretend that it's 1997, and look at the tags used by these sites, and you'll see. This phenomenon also appears in the 2006 redesign of the site. How pathetic.

For more information on the use of web standardization for public service Web sites worldwide, you can refer to the following articles: Government Web Standards usage:usa,government Web standards usage:new Zealand , government WEB Standards Usage:people ' s Republic and Mätning av grundläggande tillgänglighet (Swedish).

Web standards are not synonymous with affinity, but using web standards is the creation of an integral part of an affinity Web site, and it is often seen in the validation results that any effort has been made to make the site approachable.

When you look at the results of the Verva (Swedish administrative Development Agency, Swedish Administrative Development Office) on many Swedish public sector websites, you will find a side effect caused by the checksum. Even though the first verified sites make their home tags conform to specifications, they are still using performance class tags, a large number of inline CSS, layout tables, and blank GIF images that apply unwanted replacement text (alt texts). This false surface makes me very sad, rather than doing nothing, and is better than using the Verva method of cheating.

It is clear that the low affinity and widespread poor quality of most public sector websites are unsatisfactory (2). But to a certain extent, this is understandable--unless you have a certain understanding of the affinity of the site, it is difficult to determine whether a site has affinity. Many public sectors have hired a network agency to build their web sites, because the organizations themselves do not understand HTML. This makes it difficult for those responsible to determine whether their Web sites are approachable, and whether the companies they hire to do the job are right.

Unfortunately, many network organizations have little interest in setting up a high-quality Web site, nor are they using the best strategy or ensuring the affinity of the site. Why is this, I really do not know. In theory, WEB practitioners should be proud of their outstanding tasks and should always try their best. But it is clear that there is always a gap between theory and reality.

The marketing approach used by some CMS vendors is also a major problem. When they are marketing, they falsely and deliberately claim that the sites based on their software are approachable and fully compliant with web standards, and they are focused on how to recruit potential buyers with WYSIWYG editors, pop-up menus, drag-and-drop integration with Microsoft Office, and more. As long as the CMS vendors are allowed to sell their products with false information, even though there are already a handful of network organizations that are going to make sure that their CMS generates canonical, semantic, and affinity code, I'm afraid we will never see the light of day.

Well, now that I've finished the passionate speech, let's get back to the point of this article: How do you do some basic Web site affinity assessment.

Preparation: Install some tools
First, I recommend downloading and installing some handy tools that make it easy to evaluate affinity:

Firefox Browser
Web Developer extensions for Firefox
HTML Validator extension for Firefox
Fangs Extension for Firefox
text-based Browser Lynx (3)

You may have installed one or all of these tools, but if you haven't installed them, download them now and load them up.

Check Point

The checkpoints mentioned in these articles cover many aspects that often cause affinity problems. Some of these are more common. This is a total of 18 checkpoints:

General Inspection

Validating HTML and CSS
No frames, please.
Automatic affinity Checking Tool
Pictures and alternate text
Make sure Javascript is free of distractions
Increase text font
Looking for semantic markup
Disable CSS
Using fangs to simulate a screen reader
Digging deeper
Color contrast
Document title
Link text
Non-HTML format
Platform Differences
Keyboard navigation
Data table
form controls and labels
Using a screen reader

Comments

1, on the official website of the world's Web site, it is defined as:

People with disabilities can perceive, understand, navigate, and interact with the WEB, and which they can contribute to th E Web

2, a few days ago, I just made some survey and contrast to the website of 10 universities in China, the domestic site has not yet risen to the level of affinity.

3, Lynx has an online version , so do not have to install into the machine.