Responsive - Pod Request Access (Desktop, Tablet, Mobile)

Hi Juan, congrats on your solution; here are some comments that might help you to improve it:

Accessibility and semantics

• You are duplicating nodes to have the same component depending on the device, so you have two articles, one for mobile and one for tablets or desktop ones. Try to create you elements using only one component, no matter the device and avoid duplicating it as it's a bad practice.
• The email input has a visual accessibility issue, as it does not have any other state but its default one. Any user that tries to navigate on the page may get lost once it sets the focus on this element.
• Even if you're validating the form before its submission, you may enhance the experience using some attributes like: required and aria-required so not just the form has a native validation status but any assistive technology to be able to correctly mention it; aria-labelledby and aria-describedby so assistive technology would be able to give a better context on the input state when focused or even when the user has an error on it; and an aria-invalid="true" when it has an error state.
• The span.text-fem-red may have an aria-live="assertive" attribute so the assistive technologies may read out loud any error message.
• Regarding your nav elements; the anchors should be wrapped in an ul to enhance its semantics and also, each link should have a descriptive text, it's not enough with the alternative text in the images.

Styles

• Do not let the browser have its native focus state to provide a unique experience across devices. Each browser may use this outline differently.

Vue

• You can modularize your solution by creating smaller components instead of handling one single App component. Some candidates to components may be icon, request-form, and podcasts among others.

Others

• You have a prettier config but the project is 1) depending on the developer to install it on his/her machine instead of define a local version in your package.json dev dependencies, 2) there is an improvement here you can make using modules like husky to prevent commits with code that has not been run prettier yet and lint-stage to only run prettier on staged files; this latter module will be helpful on large projects with thousands of modules.

I hope you find it useful. I'm happy to look at your solution if you make other changes.