Update Universal Design

Universal-Design.md

@@ -1,26 +1,30 @@
+[[_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. 
+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.
+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.
+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.
+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.
+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.
@@ -35,24 +39,28 @@ Our steps to follow this principle include, but are not limited to:
 
 <br />
 
-## UD Testing
+## UD Testing with Microsoft's "Accessibility Insights for Web"
-### Microsoft's "Accessibility Insights for Web" Tests
+
-#### First test of web application using Microsoft “Accessibility Insights for Web” – MVP
+All test summaries can be found in documentation/UD_Tests
-__Purpose__
+
+### 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__
+#### Method
 
 Used the “Accessibility Insights for Web” tool by Microsoft to run automatic, partially-automatic and manual tests on each page. 
 
-__Results__
+#### Results
 
-##### “Tournaments” page
+**Tournaments page**
 - All checks passed 
 
 
-##### “Create tournament” page 
+**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
@@ -67,11 +75,11 @@ Solutions:
 - Removed select element in favor of a slider
 
 
-##### “Manage tournaments” page
+**Manage tournaments page**
 - All checks passed
 
 
-##### "View tournament” page
+**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
@@ -81,11 +89,11 @@ Solution:
 - Changed button color to increase contrast
 
 
-##### “Manage teams” page
+**Manage teams page**
 - All checks passed
 
 
-##### “Edit teams” page
+**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
@@ -95,3 +103,41 @@ Issues:
 Solutions: 
 - Changed the ARIA id attribute on one of the elements
 
+<br />
+
+### 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 listelements was left from an old revision
+  - Ensures `<li>` elements are used semantically
+  - WCAG 1.3.1
+
+Solution:
+- To ensure a responsive design, all default `<ul>` and `<li>` elements were turned into MUI <Box> 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_