Page check reviews your page for any spelling, link, W3C validation and accessibility errors. It is the same options as final check, but can be run at any point while a page is checked out to you.
It checks the rendered version of your page: i.e., what the page looks like on the live website. This includes any reusable content used on the page.
To run page check:
- In Content > Pages, hover over a checked-out page and select Review > Page Check.
When viewing a checked-out page, click the check icon in the top toolbar.
If you try to run Page Check from an open editable region, you will be prompted to save your changes first.
- The available options are:
- Output Selector: Some pages create more than one item when published, i.e. both a web page (html) and a PDF file. Use this dropdown to change which item is being reviewed by the checks.
- Run All: Click to run all available checks (Spelling, Links, W3C Valid, and Accessibility).
- Spell Check Language: Select a language for the spell check.
- Spelling: Checks the spelling of the page.
- Links: Checks for broken links on the page.
- W3C Valid: Checks for valid HTML and XHTML code on the page.
- Accessibility: Checks that the page conforms to accessibility standards.
- Once each check runs, it lists the number of errors underneath. Click "Show Results" to see a more detailed breakdown of the problems found.
- Click "Done" to close the window and return to editing the page so you can fix the errors.
The spelling check results list every misspelled word on the page and how many times it occurs. If you have the ability to add words to the dictionary, hover over a word and click "+Add to Dictionary," and spell check no longer counts it as misspelled.
This spell check counts not only words in the editable page content, but all words in the source code, including those in image descriptions. Additionally, words "broken up" by code are counted as misspellings. For example, writing
folde<span>r</span> would appear as "folder" in the page text, but the spell check would register "folde" as a misspelled word.
The link check results show every link on the page, whether it works or not. It lists the URL, the status of the link on both staging and production, and if applicable a status code for each entry.
|Staging, Production||The link is valid. (Link is Valid (202), all other 200 statuses)|
|Staging||The link is broken on the page in staging.|
|Production||The link is broken and points to a file that has been moved or some other miscellaneous issue. (Moved Permanently (301), Found (302), all other 300 statuses)|
|Production||The link is broken and points to a nonexistent destination. (Not found (404), all other 400 or 500 statuses)|
|Production||Link check is unable to verify if it's a valid link or not; often occurs with mailto links. (Cannot check link, all 100 statuses)|
Most web pages are written using markup languages such as HTML and XHTML. These languages are defined by technical specifications which usually include formal grammar and vocabulary that computers can understand. The W3C, or World Wide Web Consortium, is responsible for enforcing these standards, and the W3C check in OU Campus makes sure that your page obeys those rules.
While editing page content, the WYSIWYG editor does its best to ensure all your changes are valid. However, it may miss some items. Keep in mind that a W3C error doesn't always prevent a page from displaying on your website, but can cause inconsistencies on how it looks in different web browsers.
The W3C valid check results show both a summary of the check and each individual error. Each error is listed with the following information:
- Results: Summarizes the W3C validation test.
- Checked By: The tool used to perform the validation test.
- Doctype: The document type of the file being tested.
- Character Set: The syntax used in the file being tested.
- Validation Output: Summarizes the entries found in the content that either contain W3C errors or warnings.
- List View: Provides users with a list view of each error with relevant attached information.
Additionally, each item, whether an error or a warning, displays underneath the error summary. Each item identifies a line of code, along with a helper message indicating the problem and a preview of the problem content. In some instances, a solution or additional helper text is displayed with the item as well.
Accessibility check looks for issues in the page as defined by accessibility standards such as Section 508 and WCAG 2.0. It identifies three types of problems (known, likely, and potential):
- Known problems are issues that have been verified as broken or creating an error.
- Likely problems are items that the system identifies as most likely being an error, but needs to be reviewed by a user to determine if it's actually a problem or not.
- Potential problems are items where the system has identified code that may or may not cause errors, or the possibility of errors that cannot be automatically checked and require human review.
In the accessibility check results, each problem is listed with the location of the error in the source code, the name of the issue, an excerpt of the offending code, and a suggested repair.
Level 10 administrators can add exceptions to the accessibility check by clicking the "Make Exception" button next to an identified problem. Exceptions are still noted by the system but don't prevent page publish, if the page needs to pass page check to be published. When adding an exception from page check results, that exception is made for every page in the site.
Accessibility check settings and exceptions can be managed from the account settings.