Skip to content
Snippets Groups Projects

Universal Design

Last edited by Nicolay Schiøll-Johansen

Universal Design Team 14

Relevant key points from WCAG 2.1

1.1

  • .1 Add text based options for elements that aren't text based

1.2 (Not relevant, app doesn't allow for video)

1.3

  • .1 The code and look of the app should match

  • .2 Good order when navigating

  • .3 Clear instructions, more than 1 way to understand

1.4

  • .1 Colors shall not be the only factor when distinguishing button and other options
  • .2 (Not relevant, app doesn't allow for audio)
  • .3 Contrast between text and background at minimum 4.5:1
  • .4 Ability to change font size (deprioritized in favor of other functionality)
  • .5 Use text, not image of text

2.1

  • .1 Keyboard navigation (tab functionality)
  • .2 Use the standarized methods of keyboard navigation, instruct if other methods are used

2.2 (Not relevant, no content is time restricted)

2.3

  • .1 No elements of the app should blink more than 3 times per second

2.4

  • .1 Give the user the option to skip over blocks of content (deprioritized due to time contraints)
  • .2 Bold, descriptive and legible page titles
  • .3 The order of focusable items should be clear
  • .4 All links should be descriptive
  • .5 All roads lead to Rome, several ways to access each feature
  • .6 Headlines need to be clear and descriptive
  • .7 Keyboard navigation, tab function

3.1

  • .1 Description of language shall be in the code (all code is in english)
  • .2 Clearly mark code written in different language (not relevant)

3.2

  • .1 Clearly mark elements in focus visually
  • .2 Changing the values of an element does not vastly change the layout of the page
  • .3 Repeated navigational links should have a consistent order
  • .4 Elements that are the same, but on different pages should be formatted similarly

3.3

  • .1 Good feedback when wrong user input
  • .2 Good use of prompt texts
  • .3 If an error is discovered, give options for how to fix it
  • .4 On legally binding uploads etc, always provide an option to abort

4.1

  • .1 All pages should be without major coding errors
  • .2 Include tags and important elements in code

How we dealt with the design:

1.1

  • .1 We made sure images uploaded to our app could be described through titles, tags, descriptions and their metadata. But it's up to the user to decide if they want to use these features.

1.2 (Not relevant, app doesn't allow for video)

1.3

  • .1 Using FXML to lay the groundwork on most pages ensured that the code and design of the app go hand in hand. We also spent quite a bit of time making sure the structure of our code made sense and had good variable names.

  • .2 We strived throughout the entire development phase to ensure that the order of buttons and elements on the pages were intuitive. Our main tool to see if we achieved this were our user tests. We also got some pointers in our guidance meetings.

  • .3 Almost every single page has multiple ways to access them, and we also added a return to previous page button. The one page you can only access from one link is the sign up page, which is not intuitive to link to from any other location.

1.4

  • .1 Every button on our app has either text or a very descriptive icon. On no button does the actual color of the button mean anything.
  • .2 (Not relevant, app doesn't allow for audio)
  • .3 Throughout the design phase we made sure to check our contrast ratio often to ensure that we always had a higher contrast than 4.5:1. We ended up averaging a ratio of 14.34:1, with the lowest contrast being 8.64:1.

e16e84ea42b70e1bad07255fb53afd5c b70ef7dec580f5d6a84a1b097370be2c 3aedf112835c1bec9ccc603553ece57e

  • .4 We decided not to prioritize this aspect of the universal design in favor of spending more time implementing other functionality.
  • .5 The logo is the only image with text incorporated on the application.

2.1

  • .1 Frontend spent quite a bit of time towards the end of the project in order to make sure you could navigate the application using keyboard navigation. While this functionality might not be perfect on every single page, there's been made a effort to make it as usable as possible within the set timeframe.
  • .2 We used JavaFX's standard for setting focus, which seemingly is the tab key.

2.2 (Not relevant, no content is time restricted)

2.3

  • .1 There aren't any blinking elements on the application, and as GIFs are not a permitted file type to upload we don't think this will be an issue.

2.4

  • .1 We did not focus much on this due to time constraints.
  • .2 Page titles were added to all pages where we saw fit and edited due to user feedback. Titles are large and in bold font.
  • .3 Focus order goes left to right, top to bottom.
  • .4 Buttons all have descriptive texts explaining where they lead. Clickable items that don't have text have been tested in user tests and found to be intuitive.
  • .5 See 1.3.3
  • .6 See 2.4.2
  • .7 See 2.1.1

3.1

  • .1 The entire application uses the english language
  • .2 No different language used, so nowhere to mark

3.2

  • .1 Frontend added both hover and focus functionality in the CSS, and applied this to elements. Elements using this code are greyed out or slightly transparent when in focus.
  • .2 Changing values never changes the actual layouts of a page, however, it may change the displayed elements.
  • .3 Repeated navigation elements such as the navigation bar are always similar.
  • .4 Buttons, text fields and other similar elements all follow the same styling.

3.3

  • .1 An error message is usually displayed for the user when something goes wrong. This may not always be the case, as we may have missed an error.
  • .2 There are prompt texts in any text field where the user has the option to input data.
  • .3 When an error such as uploading a file that is too large is encountered, the user is informed of what error occurred. We believe these error messages to be sufficient in order to understand what to do differently.
  • .4 The user can always choose to abort before an upload is finished. However, there may be a need for a "decline" button on the upload page moving forward instead of having to use "return to previous page". this was not implemented due to time constraints.

4.1

  • .1 We've done our best throughout the process to not have any major flaws in our application.
  • .2 We've done our best to comment and tag the code properly throughout the development process.

Comments

    Please register or sign in to add a comment.