Single-page Developer Portfolio using HTML, CSS and JavaScript

Community feedback

• 

  

  Grace•32,130

  @grace-snow

  Posted over 2 years ago

  Hi

  You have some high severity accessibility issues on here that need fixing. The report covers some but I'll try to give more info in the feedback

  • social links all need accessible names. The inline svgs inside also need to be aria-hidden. You'll almost always want to do this for inline svgs as they are difficult to consistently label for all different assistive technologies
  • social links usually take people away from your site. So it's not necessary but a common convention to make them open in a new tab. If you add this functionality, make sure you add a title attribute to the links to say "(opens in a new tab)" so it's clear what's going to happen.
  • The logo link also needs an accessible name that says where the link goes. Eg "Adam Keyes - Home"
  • Just as styles should always be done mobile first, the picture element should be mobile first. The mobile image should be the default and the other image sources targeted in reverse order with min-width media query
  • not sure why there is an   in the middle of the h1. Content is usually entered separately by an ediyor and highly unusual to include non breaking spaces like that
  • the underline indicates a link everywhere else in the design, so I'd expect the underlined text in the h1 to also be a link
  • This is a full website so you need to hook up all the internal links properly. There is no reason to be using # except for the project links
  • the experience section should ideally be labelled with a visually hidden h2, then each experience item underneath would need to change to a h3
  • projects should be a h2
  • it's invalid html to have a div with links inside the picture element.
  • the languages should be list items inside an unordered list
  • if you're going to have custom validation on a form, you need to wrap each error message in an additional element that has a unique ID and aria-live attribute. Then each input should be aria-desciribedby that ID. These errors should then not be read out to screenreaders by default, but the tools know to "watch" those regions for changes and would automatically read out the error message when it appears and programmatically link the error message to its input on focus
  • write proper error messages
  • if writing custom validation you should add the no validate attribute on the form
  • use autocomplete attributes on name and email fields
  • same feedback for footer as in the header re links and labelling etc

  Style wise I've only looked on mobile. Looks OK but I think the links should wrap onto a new line when needed and add some more space between each project on mobile. Test down to 320px wide and you should see what I mean - it all just gets a bit cramped

  21