This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
[[TOC]]
Good universal design is very important for any product. Particularly with web applications like ours, it can be critical to achieving good user experiences.
To achieve great Universal Design, we followed Don Norman's seven fundamental design principles.
Don Norman's seven design principles
1. Discoverability (Visibility)
Discoverability offered a certain challenge to us, as we set ambitious goals for our product and wanted to include all functionality we and the user deemed necessary. This meant that the front page needed options for editing or viewing each tournament, creating new tournaments, viewing tournament history, user profiles and logging out. For discoverability we could have added all these functions to the front page of the application, however, this would go against other principles. We decided that the most important functions that would see the most use were creating, editing and viewing tournaments. For this reason, we added obvious functionality for performing these functions on the front page, and placed the history, profile and logout functions in a hamburger menu. We feel that this gives good discoverability as it is easy to understand what the web application is meant to be used for, while also having all the functionality available. All the other pages also have good discoverability, with all functionalities clearly visible and labeled as soon as the page is open. The user will also have an expectation of what a page is used for, as they have clicked a clearly labeled button to get there.
2. Feedback
We are using Material UI snackbars throughout the web application to provide continuous feedback to users. The snackbars have been color-coded (i.e., red for error), to provide the user with an instant understanding of the purpose of the message. When tournaments are created successfully, the user will be notified, and when a tournament creation form is submitted with errors, the user will be informed about this. When a user copies the discord invite link through the edit tournament page, they are notified that the link has been copied to their clipboard, because without this information it would be impossible to see if the button had any function.
3. Affordance
On each functional component in our web application, there is text to describe its function. This is our way of achieving high affordance. For certain components, we have added symbols to further describe their functions. We also use colors to describe what components do. For delete buttons, we have trash can symbols and red color. For the create tournament, there is a green button with a plus symbol. We have text in addition to symbols on any component with a symbol to avoid unfortunate cultural misunderstandings.
4. Mapping
Our best example of natural mapping exists on the view tournament page, where each time a winner of a match is selected, it automatically updates the bracket and you can see the changes in real-time. For other changes to tournaments, such as editing tournaments and managing teams, a user is immediately directed to the tournament page where they can see their changes. On the front page, we have clearly placed edit and view tournament buttons in the same visual cards as the tournament they belong to, to distinguish them from edit and view buttons for different tournaments.
5. Constraints
Our way of providing the user with constraints is closely linked to what was mentioned in part 1; discoverability. We have avoided cluttering our pages with too many functional components at the same time, to make clear to the user what options they have. On each page except the front page and create tournament page we have a navigation page that greys out the page the user is currently on. This informs the user about which page they are on and which pages they can navigate to while remaining in the same tournament. Each button that leaves a page clearly states so, to avoid leaving pages you don’t wish to leave.
6. Consistency
We have used React components with material styling to ensure that components with similar functionalities have similar styles throughout the application. Buttons for generation or creation are green, while buttons for deleting are red. Neutral buttons that navigate to pages within a tournament are blue. Big, filled buttons consistently represent more significant actions while smaller, outlined buttons represent smaller changes. All tournaments on the front page have the same size and style, no matter what it contains. All teams look the same, both on the team manager page and tournament overview. All input components also have the same styling with titles and placeholders.
7. Signifiers
Our solution to providing the user with information about where they should perform specific actions, goes hand in hand with our solution for affordance. All buttons have text, and the most significant ones also have symbols. The most important buttons are also bigger and clearly located on a card with a specific team or tournament or at the bottom of a form.
In addition to following Don Norman’s seven fundamental design principles, we know that following principle 1 of WCAG 2.1 (perceivable) can significantly improve certain users’ experiences. Our steps to follow this principle include, but are not limited to:
- Testing of each page in the web application using Microsoft's Accessibility Insights for Web.
- Sticking to the same colors and color scheme to ensure the contrast ratio stays the same throughout the web application.
- Ensuring all navigation is intuitive and obvious for the user through multiple internal and external user tests.
UD Testing with Microsoft's "Accessibility Insights for Web"
All test summaries can be found in documentation/UD_Tests
First test of web application using Microsoft “Accessibility Insights for Web” – MVP
Purpose
- Check that each page meets the requirements for WCAG 2.1 – 1 Perceivable
Method
Used the “Accessibility Insights for Web” tool by Microsoft to run automatic, partially-automatic and manual tests on each page.
Results
Tournaments page
- All checks passed
Create tournament page
Issues:
- The “Upload” button on the page did not meet the contrast ratio requirement
- Color-contrast – Ensures the contrast between foreground and background colors meets WCAG 2 AA contrast ratio thresholds
- Resources: WCAG 1.4.3
- Select-name – The select (dropdown) element did not have an accessible name
- Ensures select element has an accessible name
- Recourses: WCAG 1.3.1 And 4.1.2
- All other tests passed
Solutions:
- Changed background color to increase contrast
- Removed select element in favor of a slider
Manage tournaments page
- All checks passed
View tournament page Issue:
- The “Manage teams” button on the page did not meet the contrast ratio requirement
- Color-contrast – Ensures the contrast between foreground and background colors meets WCAG 2 AA contrast ratio thresholds
- Resources: WCAG 1.4.3
Solution:
- Changed button color to increase contrast
Manage teams page
- All checks passed
Edit teams page Issues:
- Duplicate-id-aria – two elements had the aria id of “teamNameInput”
- Ensures every id attribute value used in ARIA and in labels is unique
- Recourses: WCAG 4.1.1
- All other tests passed
Solutions:
- Changed the ARIA id attribute on one of the elements
Second test of web application using Microsoft “Accessibility Insights for Web” – Near-final product
Purpose
- Check that each page meets the requirements for WCAG 2.1 – 1 Perceivable
Method
Used the “Accessibility Insights for Web” tool by Microsoft to run automatic, partially-automatic and manual tests on each page.
Results
Tournament Overview page
Issues:
- Listitem – some list elements remained from an old revision
- Ensures
<li>elements are used semantically - WCAG 1.3.1
- Ensures
Solution:
- To ensure a responsive design, all default
<ul>and<li>elements were turned into MUI elements that had has corresponding<ul>and<li>as its component, to keep the already set up system using<li>and<ul>. The error was a result of only some elements being changed into these MUI boxes with their corresponding components, and has since been resolved.
Admins page
Issues:
- Aria-required-children
- Ensures elements with an ARIA role that requires child roles contain them
- WCAG 1.3.1
- Aria-required-parent
- Ensures elements with an ARIA role that requires parent roles are contained by them
- WCAG 1.3.1
- Duplicate-id-aria – multiple elements had the aria id of “rankSelect”
- Ensures every id attribute value used in ARIA and in labels is unique
- WCAG 4.1.1
There was not enough time left to properly address these issues