Introduction #

By using the SiteWorks plugins, together with tools provided by WordPress, a fully functional website can be published with ease.

This user guide provides a brief overview of the process, including a typical workflow, together with information on security, accessibility, etc. In this user guide, the generic term webpage(s) is used to describe Pages, Posts, Events and Group pages, and Notices. It is expected that before using these guides a u3a Web Manager and/or Administrator has followed and completed the training documents provided by the SiteWorks team.

Publishing Workflow #

To achieve a well-structured, easy-to-use website, the content creator in conjunction with the u3a committee needs to work methodically through several steps, which are identical to that used to deliver any other website:

A typical workflow includes the following steps:

• The Web Manager, content creators, and the u3a committee need to critically look at the existing website and decide, the look and feel required for the migrated site. While the data (i.e. the content) from Site Builder can be migrated – the look is not. If the site is new (i.e. a starter site), the Web Manager and the committee need to discuss the look and feel of the site, and how the media is to be resourced. A CSV input/output plugin has been provided to help data transfer for starter sites.
  
• Put together a design including consideration of where an existing or new web page is to be placed in the overall website structure, e.g., is it a group page, membership information or the welcome webpage?
  
• Sketch out how the individual webpage should look, and identify the required text and media required. In the design, use columns, white spaces etc., to enhance the visitor experience. White spaces are there to help with scanning the content and readability, making the websites seem more elegant and improving the user’s experience, and should be considered an active website element, instead of a blank or wasted space. In addition during the initial design, the accessibility issues should be addressed.
  
• Ensure that the purpose of the page is quickly visible to the reader, i.e. as soon as the page is opened – if it takes more than a couple of seconds to understand the objective of a page, you have lost the reader.
  
• When creating group and event web pages, an initial template has been predefined and will populated with u3a SiteWorks blocks by default, to allow a consistent style across all web pages of that type. The use of a Synched Pattern is recommended, if the content creator requires additional sets of blocks to appear on multiple posts or pages.
  
• Once you have completed the preparatory work, you can author your new web page using the block editor. Ensure that the text is proofread, and most importantly ensure that you have permission to use any third-party material, in particular images.

• It can be tempting to use the advanced features of WordPress during the design process. However, it should be remembered that in the future the maintenance of the site will be passed to a new web manager – ease of maintenance must be considered, by making the site future-proof.
  
• Once you have finished, preview any newly edited web page as a draft, and review. This is an iterative process in most cases, as all web pages except the most elementary will need some fine adjustment before and after publishing. One point to note is that u3a members use a variety of devices to view a website, hence readability checks are required, as discussed here.
  
• Only when the web page is completed, should it be published. After publishing, final checks should be made, including checking all links into and out of the web page. This includes a final readability check, to ensure the webpage is usable on a desktop, tablet or mobile device.
  
• Once published, beware that what the editor or author may think is straightforward to use, may not align with the views of the user community – be reactive to any constructive criticism.

Grammar and Spellchecking #

WordPress does not come with an installed grammar and spellcheck tool. This can be overcome by:

• Creating the initial drafts using a desktop application, such as Microsoft Word, LibreOffice Writer or Apple Pages. Once corrected the text can be copied and pasted into the WordPress Page or Post.
• Installing a grammar and spellchecker plugin (for example Grammarly) to the browse used to edit the site. This is the recommended approach as the content creator does not have to keep swapping between applications as pages or posts are created.
• Ensure the page or post is proofread before publication.

Virus Scans #

All the websites hosted by the SiteWorks project are protected by Imunify360.  All file transfers are scanned for malware, and the server is regularly scanned.  So when Site Builder files are uploaded to a SiteWorks site as part of the migration process they are automatically checked for virus, malware, etc..  Imunify360 also runs a daily scan of the file system and the databases of every account and the system admin team would be alerted in the event of any issue being found.   Imunify360 is configured to offer the highest level of protection and will immediately terminate any script if an attack is detected or immediately quarantine any suspect file found during a scan.

Website Terms and Conditions #

It is strongly advised that an u3a add a set of Website Terms and Conditions to their Website, for this reason, an approved document is provided in the distribution. The document is provided in draft form with the title Website Terms of Use. 

This page MUST be edited by the u3a Web Manager with the approval of the committee before use, by making changes to the highlighted text and providing a link to the privacy policy of the specific u3a.

The u3a is free to modify the text to suit their circumstances but should take legal advice before making any significant changes, or additions.

If a u3a adds any plugins other than those currently provided as part of the SiteWorks distribution the u3a must also update the statement to cover any cookie use by such plugins or any implications the plugin may have for processing personal data.

Once the page is published, a link to the page will appear in the website footer (provided the u3a is using the standard footer provided with the theme). Further information regarding editing the footer is provided here.

Search Engines #

For your site to be located by search engines, so that it becomes visible following a Google or similar searches, the Search Engine Visibility flag needs to be correctly set. From the Dashboard menu, select Settings ⇒ Reading, then at the bottom of the page ensure the Discourage search engines from indexing this site tick box is not ticked. The Save Changes must then be selected.

Accessibility Issues #

In developing a website, the Web Manager needs to consider the usability of the site. Thus, it is critical to ensure a u3a website resolves common web accessibility issues to help people with disabilities become better engaged with the aims and objectives of the u3a movement. As a first step, web managers and content providers should consult the u3a readability guidelines for more information.

To address this issue the Word Wide Web Consortium, W3C, has developed the Web Content Accessibility Guidelines (WCAG) as part of the Web Accessibility Initiative, which has been developed by W3C, the full document is available, but is highly technical, however, a checklist is provided by the W3C is located here. A summary of the needs of an elderly person is provided here.

From the web manager’s and content provider’s perspective, the following significant points should be noted:

Providing text alternatives to non-text content #

The use of Alternative text or ‘Alt Text’ should be completed when images are uploaded to a webpage. This feature helps visually impaired users understand, the content and context of an image. A short description of the image, in the context of the webpage, should be inserted in the Alt Text box, both upon uploading the image and if need be when the image is placed on a web page. When the page is displayed and the visitor is using software tools designed for the visually impaired, which read aloud the page content, this description will be included as well. The Alt Text is NOT displayed on the screen, as it is considered metadata. The UK Government has an overview of good practice, a summary is provided here, while how to include Alt Text into SiteWorks is discussed here.

Ensuring Information and Structure is separate from Presentation #

This includes the use of colour, is the message clear, or if the colours cannot be perceived (i.e. the reader is colour-blind). The presentation should be clear and easy to follow. Do not use excessive linking within and between pages, as users can become easily disorientated.

Font Considerations. #

The font used in the SiteWorks has been selected for clarity. In contrast, WCAG does not specify a required or minimum font size.  What they do say is that a visitor to a web page should be able to resize all text to at least 200% of the original size.  All current browsers provide this functionality.

There is however one very important issue to note regarding text.  The standard requires all text on a page to be re-sizable.  One way of failing to meet this requirement is to use images which have text incorporated (e.g. a group name), which may not be resized by some web browsers when using zoom controls. It is recommended that text is not added to an image during editing. It should be noted the Site Builder Home Pages used this approach, which should not be carried forward into SiteWorks.

It should be noted that WordPress image captions are considered to be a text element so will be enlarged when the page is zoomed.

Colour Blindness & Web Design #

Colour blindness is the inability to perceive differences between some of the colours that non-coloured impaired users can distinguish, and affects 5-8% of males and <1% of females. Therefore a poorly designed site could exclude 1 in 20 visitors. The most common deficiencies are:

• Red-Green. In its most severe form, a person is unable to differentiate between red and green,
• Blue-Yellow. This is far less common and impacts blue and green, yellow and red, blue and green, purple and red, and yellow and pink colour combinations.

To overcome this challenge, maximise the contrast between background and text, i.e. black on white, and also prioritise information, the higher the content is in importance, the more essential is it to make it colour-blind safe. Elements of the navigation menus, headers and sub-headers can be given more artistic treatments because users seldom stare at these elements for long periods. Navigation should stand out from the content and visitors should be able to quickly differentiate between the two.

Any links or buttons on the site that are essential in aiding the user to accomplish their tasks would fall high on the essential list. The standard rule: any content that the user may look at for more than two seconds should be made visible and have a high contrast ratio.

Each element on a web page should have more than one cue. Images, links, buttons, and other similar elements should be enhanced with an image, shape, positioning or text. For example, a link should be highlighted by colour as well as being underlined, hence removing the colour, the underline will let visitors with colour blindness know that it is a link.

Making text readable #

The Web Content Accessibility Guidelines specify a high contrast ratio, i.e. the perceived difference, between the foreground and background colours.  The u3a Brand Guidelines show recommended colour combinations which meet this standard, and the WordPress colour picker for text will inform you if you have chosen a colour foreground/background combination that is below the recommended level.

Web Managers should not change the style of the templates using an option within the Site Editor, as this will overwrite the u3a brand recommendations, and in all probability raise some readability issues.

Page Structure #

Ensure the structure of pages follows a set pattern. For example on group pages, provide all the key information either at the top or bottom (i.e. be consistent), so that the u3a member can easily find details as required. Once a group page layout has been finalised, it can be stored as a Synched Pattern for use across the site, without having to replicate each page individually.