chore: 폼 컴포넌트 테스트하기 리드미 초안 #1
Conversation
|
|
||
| ### input과 label의 접근성 배우기 | ||
| 두번째 실습은 새 회원을 추가하는 폼을 만들어보는 예제입니다. |
There was a problem hiding this comment.
생각해보니 무엇을 배우는지 요약이 앞에 간단히 있으면 좋겠네요.
그리고 요구사항을 직접 파악해볼 수 있게 이미지를 첨부해야겠습니다.
|
|
||
| ### 폼 작성하고 제출 테스트하기 | ||
| 1. 이름과 회사 이메일을 입력 후 추가하기 버튼을 누르면 폼이 제출됩니다. |
There was a problem hiding this comment.
어디에 입력하는지 이야기하면 좋겠습니다. 이름과 회사 이메일을 폼의 텍스트 인풋에 넣는 거였죠.
| 1. 이름과 회사 이메일을 입력 후 추가하기 버튼을 누르면 폼이 제출됩니다. | ||
| 2. 이름과 회사 이메일을 입력하지 않으면 입력해달라는 에러 메세지를 보여줍니다. | ||
| 3. 회사 이메일 입력 값이 이메일 형식과 다르면 "올바른 이메일 형식을 입력해주세요" 에러가 뜹니다. | ||
| 4. 이름 입력 값이 24자를 초과하면 "이름은 24자까지만 입력 가능합니다" 에러가 뜹니다. |
There was a problem hiding this comment.
에러가 발생하지 않는 게 맞습니다. maxLength={24} 로 설정하면 24글자 이상 입력할 수가 없으니까요.
이걸 테스트할 때에는 보통 25자를 입력해도 24자까지만 입력되는 걸 봅니다.
|
|
||
| ### 에러 메세지 테스트하기 | ||
| #### 2-1. input 태그를 label 태그의 자식으로 두는 것의 이점 |
There was a problem hiding this comment.
label로 input에 접근 가능한 이름 달아주기
정도로 하면 좋겠네요.
|
|
||
| ### ErrorMessageForm 추출해서 리팩토링하기 | ||
| label 안에 input 태그가 있으면 `<label>`을 클릭해도 `<input>` 요소에 포커스가 되어서 접근성 및 사용성이 향상 향상됩니다. |
There was a problem hiding this comment.
이거는 label 안에 input을 넣는 이유 중에 하나일 뿐이라서. 다양한 이유를 목록처럼 언급하면 좋겠습니다. label이 필요한 이유는 기본적으로 모든 input에는 눈에 보이는 텍스트 라벨이 있어야 한다는 것이 표준이기 때문입니다.
placeholder만 있어도 안 되고. 눈에 보이지 않는 라벨을 쓰는 것도 안 되는데. 여기서는 그런 안 좋은 예시와 관련 자료 링크를 달아줘야겠습니다.
|
|
||
| **aria-label** | ||
|
|
||
| - 버튼, 링크, 입력 필드 등 시각적인 라벨이 없거나 충분하지 않은 요소에 사용합니다 |
There was a problem hiding this comment.
버튼이나 링크는 보통 텍스트가 곧 접근 가능한 이름입니다.
aria-label은 그래서 되도록 안 쓰는 게 좋고, 예외적으로 쓰이는 곳은 보통 아이콘 버튼처럼 자체에 라벨이 없는 경우입니다. 이런 경우에는 아이콘에 alt를 달아줄 수도 있고, 버튼에 aria-label을 달아줄 수도 있습니다.
이 경우에도 가능하면 aria-labelledby 를 써서 눈에 보이는 텍스트 라벨과 연결해주는 게 좋습니다.
| > `aria-*` 속성은 요소의 접근성을 높이기 위해 추가적인 정보를 제공하는 데 사용됩니다. | ||
| > `role` 속성과 `aria-*` 속성은 상호 보완적으로 사용될 수 있지만, 완전히 대체할 수는 없습니다. | ||
| > 따라서 `div`나 `span`과 같은 요소에 특정 역할을 부여하고자 할 때는 `role` 속성을 사용하고, | ||
| > 필요한 추가 정보를 제공하기 위해 `aria-*` 속성을 함께 사용합니다. |
There was a problem hiding this comment.
aria- 속성들은 추가 정보를 제공한다고 하면 옵셔널한 것처럼 보이는데 사실 그렇지 않습니다.
role은 말 그대로 역할을 부여하고, role마다 마땅히 가져야 하는 aria-* 속성들이 있습니다. 예를 들어 모달을 여는 버튼이면 aria-haspopup을 가져야 하는 식입니다.
이런 말은 단언하기 보다는 출처를 달아주는 게 좋겠습니다. 제가 aria 표준에서 정의한 말들을 출처를 달아놓을게요~
| { | ||
| typeof errorState.name === "string" && ( | ||
| <div | ||
| role="alert" // 스크린 리더가 이 요소가 경고임을 알 수 있게 해준다. |
There was a problem hiding this comment.
role=alert에는 그 외에도 많은 역할이 있습니다. 예를 들어 alert는 암묵적으로 aria-live 처럼 사용자가 현재 이 요소를 읽고 있지 않았더라도, alert로 나타난 요소들을 읽어줍니다. 토스트도 alert role을 가지고 있는 이유죠.
|
|
||
| - boolean | ||
| - 입력 유효성 검사가 필요한 폼 필드에 사용합니다. | ||
| - 스크린 리더는 이 속성을 통해 폼 필드의 유효성 상태를 사용자에게 알립니다. |
There was a problem hiding this comment.
유효성 상태라고 하면 말이 좀 모호하게 들리는데요. 사용자가 입력한 값이 유효하지 않음을 알려주는 값이고, 시각적으로는 붉은 테두리나 글씨 등에 대응이 됩니다.
|
|
||
| **aria-lablledby** | ||
|
|
||
| - 복합 위젯, 모달 창, 그룹화된 폼 요소 등에 사용 |
There was a problem hiding this comment.
좀 더 구체적이고 와닿는 예시면 좋겠네요.
모달이나 section 같은 group, list 등에 많이 쓰입니다.
|
|
||
| **요구사항 1: 이름과 회사 이메일을 입력 후 추가하기 버튼을 누르면 폼이 제출됩니다.** | ||
|
|
||
| ```tsx |
There was a problem hiding this comment.
테스트 코드를 바로 작성하기보다는, 먼저 주석만 적어둔 예시코드를 보여주는 게 좋겠습니다.
| return ( | ||
| <form | ||
| onSubmit={(e) => { | ||
| e.preventDefault(); // form 태그의 기본 동작인 페이지 리로드를 방지 |
There was a problem hiding this comment.
정확히는 페이지를 리로드하는 것은 아니고, 서버에 폼을 제출하면서 get요청을 보내고, 페이지를 다시 요청하니 리로드 되는 것처럼 보이는 것이긴 합니다.
| // form 요소의 데이터를 쉽게 다룰 수 있도록 FormData 객체 생성 | ||
| const formData = new FormData(e.target as HTMLFormElement); | ||
|
|
||
| console.log(FormDataEvent); // FormData {} |
There was a problem hiding this comment.
FormDataEvent 는 어디서 나왔는지 잘 모르겠지만... formData보다는 e.target을 찍어보면 좋았겠다 싶네요. 그냥 지우는 것도 방법이겠습니다.
| ``` | ||
|
|
||
| ### 4. 에러 메세지 테스트하기 | ||
|
|
There was a problem hiding this comment.
앞에서 무엇이 아쉬워서 요구사항 2로 넘어간 건지 적으면 좋겠습니다.
요구사항 1에서는 아직 에러 메시지가 보이지 않기 때문에. 잘못된 값을 넣어도 폼이 제출 됩니다!
| </form> | ||
| ); | ||
| }; | ||
| ``` |
There was a problem hiding this comment.
이게 매우 번거롭다는 걸 강조해주면 좋겠고. 너무 많은 단계를 한 번에 처리하기보다는 여러 단계로 나눠서 실패하는 에러 메시지를 보며 구현하는 걸 보여주면 좋겠습니다.
No description provided.