Skip to Main Content
Popular Searches
Info for:
Request Info Tour Apply
In Office of Communications
High Point University > Office of Communications > Web Design Resources > Web Accessibility

Web Accessibility
In Office of Communications
Back to Web Design Resources

WordPress

Web accessibility means that there are no barriers that prevent interaction with, or access to, websites by people with disabilities. All pages on the High Point University Web site are required to adhere to the following accessibility standards. Failure to comply may result in the deactivation of pages in violation.

Use Alt tags for Images
  • Images should have alt tags. Screen readers will read this text to visually impaired users.  Alt text should succinctly describe the content conveyed by the image.
  • Adding Alt Tags
    When adding a link to an image, add the alt text to the image tag as follows:             <img src=”image.jpg” alt=”Alt Tag Goes Here” />When adding images using the Add Media panel, add alt text to the right of the screen.  (Click the screenshot to view image in a new window).
    alttags
  • Complex graphics (graphs, charts, etc.) must be accompanied by equivalent text, either through alt text or a description elsewhere on the page.
  • Graphics used as links (without accompanying text description) have alt text that indicates the destination page.
  • Decorative/non-informative inline graphics should have alt=”” (empty alt).
  • Icons that accompany link text should have alt=”” (empty alt)
Make Videos and Audio Accessible
  • Provide either full-text captions or a complete text transcript alternative for publicly available videos,
  • Video or audio should not begin playing on page load.
  • Include controls to mute, pause, and stop video and audio.
Provide good Color Contrast for text and images

HPU Theme Color Combinations

White background
(#ffffff)

Black text (#231F20) 
Royal Purple text( #330072) 
Orange Red text (#d93c0d) 

Royal Purple background
(#330072)

White text (#ffffff) 

White Smoke background
(#eeeeef)

Black text (#231F20)
Royal Purple text (#330072)

Orange Red background
(#d93c0d)

White text (#ffffff) Button Use Only
  • Avoid the following color combinations, which are especially hard on color blind people: Green & Red; Green & Brown; Blue & Purple; Green & Blue; Light Green & Yellow; Blue & Grey; Green & Grey; Green & Black.
  • Essential functionality should not depend on color distinctions.
  • Images in the content should be viewable by color-blind users.
Make your navigation clear and consistent.
  • Choose clear and consistent names for your pages. The navigation object uses these page names.
  • Use Semantic HTML when appropriate.
Allow moving elements to be paused or stopped.
  • This gives users with vision impairment and cognitive disabilities a chance to see this moving content.
  • This is especially needed if important text is changing or moving in some way. Give all users a chance to read this content.
Avoid blinking or flashing effects.
  • Such effects can trigger a seizure. Make these optional or avoid them altogether.
Check your page for Accessibility Compliance

Using Google Chrome:

  1. Navigate to the page that you would like to check.
  2. Right-click on the page and select Inspect to launch ChromeDev Tools.
  3. Select the Lighthouse option (from the tabbed navigation) and Generate the accessibility report for the page.

Learn more about Lighthouse

WordPress Accessibility Guidelines

The High Point University website will be designed and developed to be compliant with the Web Content Accessibility Guidelines (WCAG) as follows: 

Level A

Supports programmatic validation: 

  1. <html lang=”en”> (or lang=”fr”) is defined. 
  2. HTML formatting is correct: 
  3. Every element has an associated end tag 
  4. Elements don’t have duplicate attributes 
  5. Elements are nested correctly (no blocks inside spans, only li’s as direct ul/ol children) 
  6. Every id is unique 
  7. Every page has an appropriate/meaningful <title></title>. 
  8. All form fields have an associated label (or an aria-label=”” if a visual label isn’t appropriate). 
  9. All images have alt tags. 

Requires manual validation: 

  1. Do not do anything that might cause seizures (nothing flashes more than 3 times). 
  2. If a CAPTCHA is required, use an alternative. 
  3. Avoid content that is timing sensitive (ie. click “next” within 30 seconds).. 
  4. Audio does not play without user input (if it must, ensure the user can easily pause/stop it with a keyboard control). 
  5. Use the most semantically appropriate HTML elements (article, aside, figure, header, footer, main, nav, section). 
  6. Purely decorative content is hidden from the screen reader: 
  7. if it’s an image use alt=”” 
  8. otherwise use aria-hidden=”true” 
  9. If an element has a meaningful background-image (non-decorative) use role=”img” and aria-label=”foo bar”. 
  10. No instructions rely on purely visual descriptions (ie. “click on the red circular button”). 
  11. DOM sequences match visual sequences (ie. if a nav is fixed to the top, it shouldn’t be the last element in the DOM, or, if clicking a button triggers a modal, the modal should come after the button in the DOM, not before). 
  12. The entire site can be navigated via the tab/shift+tab key (and at no point does the tab focus get trapped). 
  13. If content auto-updates use aria-live=”polite” and aria-atomic=”true” AND ensure users can easily stop/pause/control the frequency of the auto-updating feature. 
  14. Include a hidden skip button for content that is repeated on multiple pages (ie. skip the primary nav and jump to the main page content). Use: position: absolute; left: 10000px; top: auto; width: 1px; height: 1px; overflow: hidden; and then show the element on focus. (do NOT use width/height 0 as this will not be read by most screen readers). 
  15. The purpose of links can be determined by their text. If this isn’t possible (ie. “Learn More” link) then use aria-describedby=”foo bar”. 
  16. If an element receives focus, it should not trigger a programmatic change of focus (ie. focusing on button 1 should not trigger a programmatic focus on button 2). 
  17. When displaying a modal, use Javascript to set focus inside the modal when opening and outside the modal when closing. Also, ensure the modal has role=”dialog”. 
  18. Errors are clearly identified and are as helpful as possible (ie. suggest solutions when possible). Simply highlighting fields in red would be insufficient, each field should have a corresponding error message. 
  19. Use appropriate roles and states 
  20. anchors that look like buttons use role=”button” 
  21. Elements that act like checkboxes should be formatted like: <div role=”checkbox” aria-checked=true”></div> 
Level AA

Prior to achieving level AA compliance, all level A criteria must be met first. 

Requires manual validation 

  1. The contrast ratio of large text (at least 18pt, or at least 14pt bold) and its background must meet or exceed 3:1.1 
  2. The contrast ratio of regular text (17pt or smaller, or 13pt bold or smaller) and its background must meet or exceed 4.5:1.1 
  3. Text can be resized up to 200% without the loss of content or functionality. 
  4. No images of text are present (logos/wordmarks are an exception). 
  5. At least two methods of reaching any particular page are present (individual steps in a process are an exception, ie. checkout). Some potential methods include: 
  6. primary navigation 
  7. search 
  8. sitemap 
  9. sidebar 
  10. breadcrumb 
  11. The keyboard focus indicator (activated via the tab key) must always be visible when present. 

GDPR Compliance

The High Point University website will be designed and developed to be compliant with the General Data Protection Regulation (GDPR) as follows:  

The General Data Protection Regulation (GDPR) is a regulation by which the European Parliament, the Council of the European Union, and the European Commission intend to strengthen and unify data protection for all individuals within the European Union. The proposed new EU data protection regime extends the scope of the EU data protection law to all foreign companies processing data of EU residents. 

  1. The application has a privacy statement. 
  2. The application does not collect or process more data or for a longer duration than is strictly necessary for the intended purpose as communicated to the user. 
  3. The end users have explicitly agreed with the processing of personal data. (Pre-ticked boxes are not permitted.) 
  4. The application provides contact information on the controller that is easy to find. 
  5. The application has a separate checkbox on the registration form for each particular processing activity. 
  6. It is clear to the end user on what he/she gives permission for. This is explained transparently, concisely and understandably. Visual support is used where relevant. Especially when information is intended for a child. 
  7. If applicable, it is stated that a child may only give permission if he/she is 16 years of age or older. Otherwise, the permission of a parent is needed. It should be reasonably demonstrated that a parent has given permission. 
  8. If the application includes decision-making, it should be clear how that decision is taken. 
  9. If the application includes programmatic advertisements it must be clearly authorized by the user. 
  10. The application allows end users to view and adjust data that is actively shared (by the user). 
  11. An appropriate assessment has been made when data is pseudonymized and this process is tuned. 
  12. Appropriate technical and organizational measures are taken to ensure a level of security appropriate to the risk, including inter alia as appropriate: 
  13. the pseudonymisation and encryption of personal data. 
  14. the ability to ensure the ongoing confidentiality, integrity, availability, and resilience of processing systems and services. 
  15. the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident. 
  16. a process for regularly testing, assessing and evaluating the effectiveness of technical and organizational measures for ensuring the security of the processing. 
Rights of the Data Subject

The right of access by the data subject  

The data subject has the right to obtain confirmation from a controller that data is being processed about him. In that case, the following information must be provided: 

  • the purpose of the processing 
  • which categories of personal data are processed 
  • which third parties have also received this personal data 

In addition, it is the intention that the person concerned gains ‘access’ to the data processed about him. This could be done, for example, by exporting the file that was created about the person concerned. 

Right to rectification  

The data subject has the right to have his data rectified if they are not correct or incomplete. If you have shared this information with third parties as the controller, then you must inform these parties about this rectification if possible. 

Right to erasure (‘right to be forgotten’)  

Due to the right to erasure, also known as the ‘right to be forgotten’, the data subject has the right to request the removal of his data. The right can be used in the following cases: 

  • the data is no longer needed in relation to the purpose of the processing 
  • the data subject withdrew his consent to the processing 
  • the data subject objects to the processing, and there is no demonstrable legitimate interest to continue this processing 
  • the data has been processed unlawfully 
  • the data must be removed because of a legal obligation 

Right to restriction of processing  

The data subject can request a blocking of the processing. This means that except that the data is retained, no other processing may take place (including no deletion). 

Right to data portability  

The data subject has the right to receive the personal data he has made available to the controller, in a structured and widely used format (this format must be machine-readable, for example, a CSV file or in JSON format). He has the right to transfer this data to another controller. 

Right to object  

The data subject may object to the processing of his data if the processing has been effected on the basis of the following points: 

Processing is necessary for a general interest task or for a task in the exercise of the public authority entrusted to the controller 

The processing is necessary for the representation of the legitimate interests of the controller or of a third party 

If the objection of a data subject is well-founded, the processing must be discontinued, unless you can prove that there are demonstrable legitimate reasons for continuing with the processing, or because the data are necessary for legal claims. If it concerns an objection related to direct marketing, the processing must be stopped at the moment the objection comes in. 

Important Information for the Controller

If an end user has made the request to delete the data, the controller is responsible for deleting the data from itself and other parties. 

If the controller pursues a different purpose with the data then has been reported in advance, this must be communicated to the end user before commencing the processing of data for that purpose. 

In the case of a personal data breach, the controller shall without undue delay and, where feasible, not later than 72 hours after having become aware of it, notify the personal data breach to the supervisory authority. 

The controller needs to take appropriate technical and orgiastic measures and should be able to demonstrate that the processing is carried out in accordance with this regulation. 

The processor does not employ another processor without the prior written consent of the controller. 

Processing of personal data from special categories is prohibited unless the person has explicitly given permission for confidentiality of the personal data for one or more well-defined purposes or the data apparently made public by the person himself.