HAN WCAG Cooperation - Test environment documentation

Last modified 05 Feb 2024 10:54 +01:00

 

Cooperation introduction

Evolveum is working with Internet2/InCommon and several universities to move midPoint Self-service interface to be accessible by end users with disabilities. We have done internal analysis for WCAG 2.0 and we are being asked lately to get an external independent review and guidelines for WCAG. We are also interested in getting guidance to get external resources (people:developers/testers, grants) to implement the guidelines in our Self-service interface.

HAN University declared that it has a test team that can perform a quick check according to WCAG 2.1 guidelines and expressed interest to cooperate in the future to improve the environment (design, test, implementation) of midPoint according to the submitted requirements.

As part of the NGI grant, HAN created a small testing team consisting of designers, developers, and accessibility testers. Some of their team members have worked with Bootstrap in the past. In general, however, their advice tends to be more architectural and technology agnostic (e.g., HTML, CSS, UI tools, data formats), leaving their NGI partners to discover the technical details on their own to fix very specific bugs.

Point of interest

The main reason for the collaboration is to improve Midpoint’s environment in terms of self-service. The purpose is to make the environment flexible and adaptable for people with disabilities and thus to make the overall work with the platform easier and usable for all without any discrimination.

The aforementioned self-service consists of 4 basic parts:

Self-service item Definition

Dashboard (Home)

Dashboard is configurable object in midpoint, providing basic information about state of Midpoint/User. The dashboard contains the basic most important data in order to deliver information about the user’s status as quickly as possible. This is mainly about the user’s accesses, requests and other miscellaneous information whose importance is specifically determined by the client. Elements can be in the form of a dashboard, table or widget.

Profile

It is used to manage basic user information in midPoint. It consists of various attributes whose values can be freely managed by the user (if allowed by internal policy). These are then automatically (in most cases) provisioned to the user’s assigned accounts in the associated applications/accesses. Among other things, from here the user can manage his accesses, see his accounts, track history, etc.

Credential management

This functionality is used to quickly reset/change password(s) for user account(s).

Access request

Functionality used to request access on demand. The mechanism imitates shopping in an e-shop where the user chooses/can choose from a catalogue of different accesses, add them to the basket, specify the activation period and then send a request ("order").

Approval process (Bonus)

A more advanced feature extending the access request process (for example). The process is that a specific user has been given the ability to evaluate access requests and decide on the outcome.

 

Environment

Pre-requisities

When you open the link below, you will be taken to the platform login screen. Your login details can be found below in the "Account information" section. Once logged in, you will be taken to the main "Home" screen. The interface consists of a main menu used for navigation (left), a title bar with additional information and features (top), and a dynamic window that displays content based on the item you selected from the navigation.

Link to environment: https://han-demo.evolveum.com/
 

Accounts information

Role Login Password Description

Administrator

Administrator

5ecr3t

Super account (use if you want to roam around)

Basic User

jdoe

123456

Main persona representing basic user

Approver

jsmith

asdfgh

Persona used for approval process

 

Taskflow

Dashboard (Homepage)

Home page consists of different configurable widgets. For now, there are two types of widgets, link widgets and preview widgets. Link widgets can be configured and used for better and quicker navigation to desired pages (even external links are supported). Preview widgets show concrete data, and it is also possible to define custom navigation actions. The example of such action is Request access button in My accesses preview widget, which will take a user to the access request process. (Discover more here)

In this process is important to keep the observation capability simple and the scanning difficulty as easy/efficient as possible. Questions are: Is everything understandable? Is everything visible? Is everything legible?

    Task 1: Observe the environment and flow of login process
 
    Task 2: Observe the environment of Dashboard/Homepage
 

Profile management

On the Profile page, all the necessary information about the logged-in user (or service) are shown. Information that are shown are influenced by the authorizations and GUI customizations. With combining these two mechanisms, it is possible to define what kind of information will be shown to concrete (logged-in user). It is important to have this possibility to define these restrictions, because there might be different users with different rights, e.g. end users, administrators, operators. End user can be restricted to perform some actions, but administrator can do anything. (Discover more here)

    Task 1: Observe the environment

Task 2: Update the profile (expand for solution)
1) Login as jdoe
2) Go to Profile (from side menu)
3) Click on "show empty fields" at the end of form
3) Choose input field and change the values (e.g. Nickname value change to JJ or e-mail)
4) Click Save (green button at top) to apply change
5) Observe form of saving process

 

Credential management

Changing password functionality is located on the separate page to make this process easy and fast. This page contains only the essentials to make the process as quick and straightforward as possible. The user is asked to enter their old password, the new password and repeat the new password again. A password strength indicator assists the user in the password change process, along with password conditions, which are located on the right side. For more complex configurations, the user is also supplied with a section in which the user can select which resources will be affected by the change and can also be informed whether the change can occur at all. (Discover more here)

    Task 1: Open Credentials from sidemenu and observe the environment and layout

Task 2: Update the password (expand for solution)
1) Login as jdoe
2) Select Credentials from side menu
3) Fill previous password and the new one (e.g. 123456 -> 654321)
4) Click Change password
5) Remember a new password and use it for future logins as jdoe
6) Observe saving process

 

Access request

Role (Access) requesting in the new version of midPoint has taken on a whole new look. The process tries to resemble a kind of wizard that will guide you through the entire request process and should feel and give the impression that someone is helping you. This process simply allows users to request access pretty much anywhere they need it (Application/Service/Resource/etc.) depending on the configuration of midPoint and its so-called role catalog, of course. (Discover more here)

    Task 1: Open Request access from sidemenu and observe the environment and layout

Task 2: Request a role (expand for solution)
1) Login as jdoe
2) Go to Request access (option in sidemenu)
3) Go along with the instructions (select myself)
4) Go along with the instructions (select default)
5) Observe the Shopping catalogue
6) Add to cart role named as "Employee"
7) Click "Next:Shoppig cart" button or click on Cart icon in title bar
8) (Optional) Select validity e.g. "1 month"
9) Insert reason into "comment" field (e.g. "I signed the contract and need this role for work")
10) Click "Submit my request"
11) Observe the saving process

 

Approval process

MidPoint does not have any special way how to request something. E.g. there is no special mechanism how to request assignment of a role or how to request creation of a new organizational unit. The request is simply the operation itself: user requests an assignment of a role simply by trying to assign the role to himself. When midPoint encounters an operation like this it will consult the policies (Policy Rules) and decide whether the operation needs to be driven through an approval process. If an approval is needed then midPoint will automatically compute the approvers and start a workflow process to drive the approvals. When the approval process is done then midPoint will gather the results and proceed with the operation. (Discover more here)

In order to go through this process it is important that the Role request action is executed first. Basically, the approval process is a follow-up to the Role request process.

    Task 1: Observe the environment and layout

Task 2: Approve the request (expand for solution)
1) Login as jsmith
2) Proceed to Cases > My workitems from sidemenu or from dashboard panel "My work items" (accessible also from dashboard)
3 - Optional) Open the work item (request) and observe the details
4 - Optional) Add a comment
5) Approve the request

 

(Optional) Browsing the environment as an administrator

If you’re interested, there’s still the option to explore the midPoint environment through an admin account that gives you access to every corner of the environment.  
 

Recovery to initial state

Resetting the environment serves to restore to initial state of the environment so that all flows can be executed again from the original state. The procedure for resetting is as follows:

  1. Download this Recovery file (Right-click save as)

  2. Login as administrator

  3. Search in side menu Import Object

  4. Change Overwrite existing object and Keep OID checkbox state to CHECKED

  5. Choose file and select the downloaded file

  6. Click button Import Object and wait for completition

  7. Ignore warnings/errors

 

Scans/quickscans

First quickscan

About

The first report brought us to the basic/first set of issues. The predominant problems are with color contrast and missing attributes of elements supporting accessibility. Report can be found here: Report.pdf

Changelog

  • Color contrasts were fixed

  • Added ´title´ to all elements mentioned

  • Aria role/technique was implemented

  • All images that aren’t decorative got ALT tag

  • Some elements in style of "autocomplete" component and had has a finite number of options were changed to dropdown style

  • Form elements were updated and were connected with related labels by ARIA or ´Label´

  • Most of elements which are interactive and were not tabable are now reachable by ´TAB´ key (Request access skipped)

  • Clickable parts now have ´:focus-visible´ set

  • Skiplink concept was created and implemented

Cooperation timeline

(February 2024) - Completion of final adjustments to the testing environment and restoring the connection with the university
(January 2024) - Fixing problems from quickscan considered done, started preparing environment for re-test
(November 2023) - Created a team and started solving issues from quickscan
(September 2023) - First quickscan finished
(July 2023) - Renewing contact with Han.nl
(June 2023) - Preparation of Documentation is complete
(April 2023) - Preparation of the test environment is complete
(December 2022) - Preparation of the test environment and documentation has started
(December 2022) - An introductory meeting with combined with a short presentation on the introduction to the MidPoint
(November 2022) - Initiation of cooperation and first contact
Was this page helpful?
YES NO
Thanks for your feedback