등록 양식부터 시작하겠습니다. 대부분의 회사는 사용자와 장기적인 관계를 원합니다. 그렇게 하려면 사용자가 가입해야 합니다. 그리고 그렇게 하려면 사용자에게 그 대가로 가치를 제공해야 합니다. 아무도 당신의 서비스에 가입하고 싶어하지 않습니다. 그들은 당신이 제공하는 모든 것에 액세스하거나 다음에 방문할 때 더 빠른 경험을 약속하기를 원할 뿐입니다.

등록 양식의 기본적인 모양에도 불구하고 양식을 구성하는 기본 요소(레이블, 버튼 및 입력), 수고를 줄이는 방법(이와 같은 작은 양식에서도), 확인.

그러한 단순한 형태를 선택할 때 우리는 잘 설계된 형태에서 발견되는 기본적 특성을 확대할 수 있습니다.

## 어떻게 보일지

양식은 4개의 필드와 제출 버튼으로 구성됩니다. 각 필드는 컨트롤(입력) 및 관련 레이블로 구성됩니다.

HTML은 다음과 같습니다.

 <form> <label for="firstName">First name</label> <input type="text" name="firstName"> <label for="lastName">Last name</label> <input type="text" name="lastName"> <label for="email">Email address</label> <input type="email" name="email"> <label for="password">Create password</label> <input type="password" name="password" placeholder="Must be at least 8 characters"> <input type="submit" value="Register"> </form>

레이블은 토론이 시작되는 곳입니다.

## 레이블

모든 사람을 위한 접근성 에서 Laura Kalbag은 모든 사람의 사용자 경험을 개선하는 4가지 광범위한 매개변수를 설정합니다.

• Visual : 보기 쉽게 만듭니다.
• 청각 : 듣기 쉽게 만듭니다.
• 모터 : 쉽게 상호 작용할 수 있습니다.
• 인지 : 이해하기 쉽게 만듭니다.

이러한 각 관점에서 레이블을 보면 레이블이 얼마나 중요한지 알 수 있습니다. 시력이 있는 사용자는 읽을 수 있고, 시각 장애가 있는 사용자는 스크린 리더를 사용하여 들을 수 있으며, 운동 장애가 있는 사용자는 더 큰 타격 영역 덕분에 필드에 더 쉽게 초점을 맞출 수 있습니다. 레이블을 클릭하면 연결된 양식 요소에 포커스가 설정되기 때문입니다.

이러한 이유로 입력을 받는 모든 컨트롤에는 보조 <label> 이 있어야 합니다. 제출 버튼은 입력을 허용하지 않으므로 보조 레이블이 필요하지 않습니다. 버튼 내부의 텍스트를 렌더링하는 value 속성은 액세스 가능한 레이블 역할을 합니다.

입력을 레이블에 연결하려면 입력의 id 와 레이블의 for 속성이 일치해야 하고 페이지에 고유해야 합니다. 이메일 필드의 경우 값은 "이메일"입니다.

 html < label for = "email" > Email address </ label > < input id = "email" >

레이블을 포함하지 않는다는 것은 신체 및 인지 장애가 있는 사용자를 포함하여 많은 사용자의 요구를 무시한다는 의미입니다. 장애가 있는 사람들에게 인식된 장벽에 초점을 맞춤으로써 우리는 모든 사람이 더 쉽고 강력하게 양식을 만들 수 있습니다.

예를 들어, 더 큰 타격 영역은 운동 장애가 있는 사용자에게 중요하지만 장애가 없는 사용자에게도 더 쉽습니다.

## 자리 표시자

placeholder 속성은 힌트를 저장하기 위한 것입니다. 필드를 채울 때 사용자에게 추가 지침을 제공합니다. 특히 암호 필드와 같은 복잡한 규칙이 있는 필드에 유용합니다.

자리 표시자 텍스트는 실제 값이 아니므로 사용자가 입력한 값과 구분할 수 있도록 회색으로 표시됩니다.

레이블과 달리 힌트는 선택 사항이며 당연히 사용해서는 안됩니다. placeholder 속성이 존재한다고 해서 반드시 사용해야 하는 것은 아닙니다. 레이블이 "이름"인 경우 "이름을 입력하십시오"라는 자리 표시자가 필요하지 않습니다. 불필요한 중복입니다.

자리 표시자는 최소한의 공간 절약형 미학으로 인해 매력적입니다. 자리 표시자 텍스트가 필드 안에 배치되기 때문입니다. 그러나 이것은 사용자에게 힌트를 주기에는 문제가 있는 방법입니다.

첫째, 사용자가 입력하면 사라집니다. 사라지는 텍스트는 기억하기 어렵기 때문에 예를 들어 사용자가 암호 규칙 중 하나를 충족하는 것을 잊어버린 경우 오류가 발생할 수 있습니다. 사용자는 종종 자리 표시자 텍스트를 값으로 착각하여 필드를 건너뛰고 나중에 다시 오류를 발생시킵니다. 흰색 바탕에 회색 텍스트는 대비가 충분하지 않아 일반적으로 읽기 어렵습니다. 게다가 일부 브라우저는 자리 표시자를 지원하지 않고 일부 화면 판독기는 이를 알리지 않으며 긴 힌트 텍스트가 잘릴 수 있습니다.

그것은 본질적으로 단지 텍스트에 대한 많은 문제입니다. 모든 콘텐츠, 특히 양식 힌트는 좋은 것으로 간주되어서는 안 됩니다. 따라서 자리 표시자를 사용하는 대신 다음과 같이 컨트롤 위에 힌트 텍스트를 배치하는 것이 좋습니다.

 <div class="field"> <label for="password"> <span class="field-label">Password</span> <span class="field-hint">Must contain 8+ characters with at least 1 number and 1 uppercase letter.</span> </label> <input type="password" name="password"> </div>

힌트는 레이블과 <span> 내부에 배치되어 다르게 스타일을 지정할 수 있습니다. 레이블 내부에 배치하면 화면 판독기가 판독하고 적중 영역을 더욱 확대합니다.

대부분의 디자인 작업과 마찬가지로 이것이 이 기능을 달성하는 유일한 방법은 아닙니다. ARIA 속성을 사용하여 힌트를 입력과 연결할 수 있습니다.

 <div class="field"> <label for="password">Password</label> <p class="field-hint">Must contain 8+ characters with at least 1 number and 1 uppercase letter.</p> <input type="password" name="password"> </div>

aria-describedby 속성은 id 로 힌트를 연결하는 데 사용됩니다. 레이블의 for 속성과 같지만 그 반대입니다. 컨트롤의 레이블에 추가되고 잠시 후 읽습니다. 이 예에서 "password [pause]는 최소한 하나의 숫자와 하나의 대문자와 함께 8개의 더하기 문자를 포함해야 합니다."

다른 차이점도 있습니다. 먼저 힌트(이 경우 <p> )를 클릭하면 컨트롤에 초점이 맞춰지지 않아 적중 영역이 줄어듭니다. 둘째, ARIA의 지원이 증가함에도 불구하고 기본 요소만큼 잘 지원되지는 않을 것입니다. 이 특별한 경우 Internet Explorer 11은 aria-describedby 지원하지 않습니다. 이것이 ARIA의 첫 번째 규칙이 ARIA를 사용하지 않는 것입니다.

"요소의 용도를 변경하고 액세스할 수 있도록 ARIA 역할, 상태 또는 속성을 추가하는 대신 이미 기본 제공되는 의미 및 동작과 함께 기본 HTML 요소 또는 속성을 사용할 수 있다면 그렇게 하십시오."

부동 레이블

Matt Smith의 float 레이블 패턴은 레이블을 자리 표시자로 사용하는 기술입니다. 레이블은 컨트롤 내부 에서 시작하지만 사용자가 입력할 때 컨트롤 위에 떠 있으므로 이름이 지정됩니다. 이 기술은 기발하고 미니멀하고 공간 절약적인 특성으로 인해 종종 찬사를 받습니다.

불행히도 이 접근 방식에는 몇 가지 문제가 있습니다. 첫째, 레이블과 힌트가 동일하기 때문에 힌트를 위한 공간이 없습니다. 둘째, 일반적으로 디자인되었기 때문에 대비가 좋지 않고 텍스트가 작기 때문에 읽기가 어렵습니다. (사용자가 실제 값과 자리 표시자를 구별할 수 있도록 낮은 대비가 필요합니다.) 셋째, 자리 표시자와 마찬가지로 값으로 오인되어 잘릴 수 있습니다.

그리고 float 레이블은 실제로 공간을 절약하지 않습니다. 레이블은 처음에 이동할 공간이 필요합니다. 공간을 절약한다고 해도 그것이 양식의 유용성을 줄이는 좋은 이유는 아닙니다.

"단순히 입력 위에 레이블을 붙이고 모든 이점을 얻을 수 있고 문제가 없을 때 많은 노력을 기울인 것 같습니다."
— float 레이블에 대한 Luke Wroblewski

기발하고 미니멀한 인터페이스는 사용자가 멋지다고 느끼게 하지 않습니다. 명백하고 포괄적이며 강력한 인터페이스는 그렇습니다. 이와 같이 양식의 높이를 인위적으로 줄이는 것은 설득력이 없고 문제가 있습니다.

대신 디자인 프로세스를 시작할 때 항상 존재하고 쉽게 사용할 수 있는 레이블(필요한 경우 힌트)을 위한 공간을 만드는 데 우선 순위를 두어야 합니다. 이렇게 하면 콘텐츠를 작은 공간에 압축할 필요가 없습니다.

우리는 양식의 크기를 줄이기 위한 몇 가지 덜 인위적인 기술에 대해 곧 논의할 것입니다.

## 질문 프로토콜

양식의 크기를 줄이는 강력하고 자연스러운 방법 중 하나는 질문 프로토콜을 사용하는 것입니다. 모든 질문을 하거나 양식 필드를 포함하는 이유를 알 수 있도록 도와줍니다.

등록 양식에서 이름, 성, 이메일 주소 및 비밀번호를 수집해야 합니까? 경험을 단순화하는 이 정보를 요청할 수 있는 더 낫거나 다른 방법이 있습니까?

아마도 등록을 위해 사용자의 이름과 성을 요구할 필요가 없습니다. 나중에 그 정보가 필요하면 이유가 무엇이든 그때 요청하십시오. 이 필드를 제거하면 양식 크기를 절반으로 줄일 수 있습니다. 참신하고 문제가 있는 패턴에 의존하지 않고 이 모든 것이 가능합니다.

### 비밀번호 없음 로그인

사용자에게 암호를 묻지 않는 한 가지 방법은 암호 없음 로그인 패턴을 사용하는 것입니다. 이메일의 보안을 사용하여 작동합니다(이미 비밀번호가 필요함). 사용자는 이메일 주소만 입력하면 서비스는 받은 편지함으로 특별한 링크를 보냅니다. 이를 따르면 사용자가 즉시 서비스에 로그인됩니다.

이렇게 하면 양식의 크기가 하나의 필드로 줄어들 뿐만 아니라 사용자가 다른 암호를 기억해야 하는 번거로움도 줄어듭니다. 이렇게 하면 격리된 형식이 단순화되지만 다른 면에서는 사용자에게 약간의 복잡성이 추가됩니다.

첫째, 사용자는 이 접근 방식에 익숙하지 않을 수 있으며 많은 사람들이 온라인 보안에 대해 걱정하고 있습니다. 둘째, 특히 비밀번호를 알고 있거나 비밀번호 관리자를 사용하는 사용자의 경우 앱에서 이메일 계정으로 이동해야 하는 시간이 오래 걸립니다.

한 기술이 항상 다른 기술보다 낫다는 것은 아닙니다. 질문 프로토콜은 이것을 디자인 프로세스의 일부로 생각하도록 촉구합니다. 그렇지 않으면 아무 생각 없이 양식에 암호 필드를 추가하고 끝낼 것입니다.

### 암호

암호는 일반적으로 짧고 기억하기 어렵고 해독하기 쉽습니다. 사용자는 최소 하나의 대문자와 하나의 소문자와 숫자로 구성된 8자 이상의 암호를 만들어야 하는 경우가 많습니다. 이 마이크로 상호 작용은 거의 이상적이지 않습니다.

"죄송하지만 비밀번호에는 대문자, 숫자, 하이쿠, 갱 기호, 상형 문자, 처녀의 피가 포함되어야 합니다."
— 익명의 인터넷 밈

암호 대신 사용자에게 암호를 요청할 수 있습니다. 암호는 "monkeysinmygarden"(죄송합니다. 가장 먼저 떠오르는 단어)과 같은 일련의 단어입니다. 일반적으로 암호보다 기억하기 쉽고 길이 때문에 더 안전합니다. 암호는 16자 이상이어야 합니다.

단점은 암호가 덜 일반적으로 사용되므로 익숙하지 않다는 것입니다. 이것은 이미 온라인 보안에 대해 걱정하는 사용자에게 불안을 유발할 수 있습니다.

비밀번호 없는 로그인 패턴이든 암호 문구이든 철저하고 다양한 사용자 조사를 수행한 후에만 관습에서 벗어나야 합니다. 자신도 모르는 사이에 한 세트의 문제를 다른 세트로 교환하고 싶지 않습니다.

## 필드 스타일링

양식 구성 요소의 스타일을 지정하는 방법은 최소한 부분적으로는 제품 또는 회사 브랜드에 따라 결정됩니다. 그러나 레이블 위치와 초점 스타일은 중요한 고려 사항입니다.

### 라벨 위치

Matteo Penzo의 시선 추적 테스트는 레이블을 옆이 아닌 위쪽에 배치하는 것이 양식 컨트롤이 가장 잘 작동하는 것으로 나타났습니다.

"입력 필드 바로 위에 레이블을 배치하면 사용자가 한 번의 눈 움직임으로 두 요소를 모두 캡처할 수 있습니다."

그러나 필드 위에 레이블을 두는 다른 이유가 있습니다. 작은 뷰포트에서는 컨트롤 옆에 공간이 없습니다. 그리고 큰 뷰포트에서 확대하면 텍스트가 화면에서 사라질 가능성이 높아집니다.

또한 일부 레이블에는 많은 텍스트가 포함되어 있어 여러 줄로 줄바꿈되어 컨트롤 옆에 배치할 경우 시각적 리듬을 방해할 수 있습니다.

레이블을 간결하게 유지하는 것을 목표로 해야 하지만 항상 가능한 것은 아닙니다. 컨트롤 위에 레이블을 배치하여 다양한 콘텐츠를 수용하는 패턴을 사용하는 것은 좋은 전략입니다.

### 모양, 크기 및 공간

양식 필드는 양식 필드처럼 보여야 합니다. 그러나 정확히 무엇을 의미합니까?

이는 텍스트 상자가 텍스트 상자처럼 보여야 함을 의미합니다. 빈 상자는 색칠하기 책처럼 비어 있기 때문에 "나를 채우십시오"를 의미합니다. 이것은 자리 표시자가 도움이 되지 않는 이유의 일부로 발생합니다. 그들은 그렇지 않으면 빈 텍스트 상자가 제공할 인지된 어포던스를 제거합니다.

이것은 또한 빈 공간을 boxing(테두리)해야 함을 의미합니다. 예를 들어 테두리를 제거하거나 아래쪽 테두리만 있으면 인지된 어포던스가 제거됩니다. 맨 아래 테두리는 처음에는 구분 기호로 나타날 수 있습니다. 무언가를 채워야 한다는 것을 알면서도 값이 선을 초과합니까, 아니면 선 아래로 올라가나요?

공간적으로 레이블은 이전 필드의 컨트롤이 아니라 양식 컨트롤에 가장 가깝습니다. 가깝게 보이는 것들은 함께 속해 있음을 암시합니다. 동일한 간격을 갖는 것은 미학을 향상시킬 수 있지만 사용성을 희생해야 합니다.

마지막으로 레이블과 텍스트 상자 자체는 읽고 탭할 수 있을 만큼 커야 합니다. 이것은 아마도 최소 16픽셀의 글꼴 크기와 최소 44픽셀의 전체 탭 대상을 의미합니다.

### 포커스 스타일

포커스 스타일은 더 간단한 잠재 고객입니다. 기본적으로 브라우저는 사용자, 특히 키보드를 사용하는 사용자가 자신의 위치를 ​​알 수 있도록 포커스가 있는 요소 주위에 윤곽선을 배치합니다. 기본 스타일의 문제는 종종 희미하고 보기 힘들며 다소 추하다는 것입니다.

이 경우 제거하려고 하지 마십시오. 제거하면 키보드로 화면을 가로지르는 사용자 경험이 크게 줄어들기 때문입니다. 기본 스타일을 재정의하여 더 명확하고 미학적으로 보기 좋게 만들 수 있습니다.

 input:focus { outline: 4px solid #ffbf47; }

## 이메일 필드

단순한 외관에도 불구하고 경험에 영향을 미치는 현장 구성에 들어간 몇 가지 중요한 세부 사항이 있습니다.

앞서 언급했듯이 일부 필드에는 레이블 외에 힌트가 있습니다. 이것이 레이블이 하위 범위 내에 있는 이유입니다. field-label 클래스를 사용하면 CSS를 통해 스타일을 지정할 수 있습니다.

 <div class="field"> <label for="email"> <span class="field-label">Email address</span> </label> <input type="email" name="email"> </div>

레이블 자체는 "이메일 주소"이며 대소문자를 사용합니다. "Making case for letter case"에서 John Saito는 (제목의 경우와 달리) 문장의 경우가 일반적으로 읽기 쉽고 친근하며 명사를 더 쉽게 찾을 수 있다고 설명합니다. 이 조언에 귀를 기울일지 여부는 귀하에게 달려 있지만 어떤 스타일을 선택하든 일관되게 사용하십시오.

입력의 type 속성은 email 로 설정되어 모바일 장치에서 이메일 전용 화면 키보드를 트리거합니다. 이를 통해 사용자는 @ 및 . 모든 이메일 주소에 포함되어야 하는 (점) 기호.

지원하지 않는 브라우저를 사용하는 사람들은 표준 텍스트 입력( <input type="text"> )을 보게 됩니다. 이는 포괄적인 경험을 설계하는 초석인 점진적 향상의 한 형태입니다.

### 점진적 개선

점진적인 향상은 사용자에 관한 것입니다. 디자이너와 개발자로서의 삶을 더 쉽게 만들어줍니다. 브라우저와 장치 세트를 따라가는 대신(불가능합니다!) 기능에 집중할 수 있습니다.

무엇보다도 점진적인 향상은 브라우저, 장치 또는 연결 품질에 관계없이 사용자에게 항상 합리적인 경험을 제공하는 것입니다. 일이 잘못될 때 사용자는 여전히 작업을 완료할 수 있다는 점에서 고통을 겪지 않을 것입니다.

경험이 잘못될 수 있는 많은 방법이 있습니다. 스타일 시트나 스크립트가 로드되지 않을 수 있습니다. 모든 것이 로드되지만 사용자의 브라우저는 일부 HTML, CSS 또는 JavaScript를 인식하지 못합니다. 어떤 일이 일어나든 경험을 디자인할 때 점진적인 향상을 사용하면 사용자가 특히 나쁜 시간을 보내는 것을 막을 수 있습니다.

그것은 구조와 내용에 대한 HTML로 시작합니다. CSS 또는 JavaScript가 로드되지 않으면 콘텐츠가 있기 때문에 괜찮습니다.

모든 것이 정상적으로 로드되면 다양한 HTML 요소가 인식되지 않을 수 있습니다. 예를 들어, 일부 브라우저는 <input type="email"> 을 이해하지 못합니다. 하지만 사용자는 대신 텍스트 상자( <input type="text"> )를 받게 되므로 괜찮습니다. 사용자는 여전히 이메일 주소를 입력할 수 있습니다. 그들은 모바일에서 이메일 전용 키보드를 얻지 못합니다.

브라우저가 멋진 CSS를 이해하지 못하고 무시할 수도 있습니다. 대부분의 경우 이것은 문제가 되지 않습니다. border-radius: 10px 가 있는 버튼이 있다고 가정해 보겠습니다. 이 규칙을 인식하지 못하는 브라우저는 모서리가 각진 버튼을 표시합니다. 틀림없이, 버튼의 인지된 어포던스는 감소하지만 사용자는 해를 입지 않습니다. 다른 경우에는 기능 쿼리를 사용하는 것이 도움이 될 수 있습니다.

그런 다음 더 복잡한 JavaScript가 있습니다. 브라우저가 인식하지 못하는 메서드를 구문 분석하려고 하면 히시 핏이 발생합니다. 이로 인해 다른(유효하고 지원되는) 스크립트가 실패할 수 있습니다. 스크립트가 메서드를 사용하기 전에 먼저 메서드가 존재하는지(기능 감지) 작동하는지(기능 테스트) 확인하지 않으면 사용자는 인터페이스가 손상될 수 있습니다. 예를 들어 버튼의 클릭 핸들러가 인식되지 않는 메서드를 호출하면 버튼이 작동하지 않습니다. 그 나쁜.

그렇게 하면 향상됩니다. 그러나 더 나은 것은 개선이 전혀 필요하지 않다는 것입니다. 약간의 CSS가 포함된 HTML은 사용자에게 탁월한 경험을 제공할 수 있습니다. 중요한 것은 콘텐츠이며 이를 위해 JavaScript가 필요하지 않습니다. 콘텐츠(HTML)와 스타일(CSS)에 의존할수록 더 좋습니다. 나는 이것을 충분히 강조할 수 없습니다. 너무 자주, 기본 경험이 가장 훌륭하고 성능이 좋은 경험입니다. 가치를 더 하지 않는다면 무언가를 향상시키는 것은 의미가 없습니다(포괄적 디자인 원칙 7 참조).

물론, 기본적인 경험이 기대만큼 좋지 않을 때가 있습니다. 바로 지금이 향상되어야 할 때입니다. 그러나 위의 접근 방식을 따르면 CSS 또는 JavaScript의 일부가 인식되거나 실행되지 않을 때 여전히 작동합니다.

점진적인 향상은 일이 실패할 때 어떤 일이 일어나는지 생각하게 합니다. 이를 통해 우리는 회복탄력성을 바탕으로 경험을 쌓을 수 있습니다. 그러나 마찬가지로 개선이 필요한지 여부를 생각하게 합니다. 그렇다면 어떻게 하는 것이 가장 좋은가.

## 비밀번호 필드

앞에서 설명한 이메일 필드와 동일한 마크업을 사용하고 있습니다. 템플릿 언어를 사용하는 경우 두 가지 유형의 필드를 모두 수용하는 구성 요소를 만들 수 있습니다. 이는 포괄적인 디자인 원칙 3을 적용하는 데 도움이 됩니다.

 <div class="field"> <label for="password"> <span class="field-label">Choose password</span> <span class="field-hint">Must contain 8+ characters with at least 1 number and 1 uppercase letter.</span> </label> <input type="password" name="password"> </div>

비밀번호 필드에는 힌트가 포함되어 있습니다. 하나가 없으면 사용자는 요구 사항을 이해하지 못하므로 계속 진행하려고 하면 오류가 발생할 수 있습니다.

type="password" 속성은 사용자가 입력한 내용을 작은 검은색 점으로 대체하여 입력 값을 마스킹합니다. 이것은 사람들이 가까이에 있는 경우 귀하가 입력한 내용을 볼 수 없도록 하는 보안 조치입니다.

### 비밀번호 공개

사용자가 입력할 때 값을 가리면 오타를 수정하기 어렵습니다. 따라서 항목이 만들어지면 전체 항목을 삭제하고 다시 시작하는 것이 더 쉽습니다. 이것은 대부분의 사용자가 어깨 너머로 사람을 바라보는 컴퓨터를 사용하지 않기 때문에 실망스럽습니다.

오타 위험이 증가하기 때문에 일부 등록 양식에는 "비밀번호 확인" 필드가 추가로 포함됩니다. 이는 사용자가 동일한 암호를 두 번 입력해야 하는 예방 조치이므로 노력이 두 배로 늘어나고 사용자 경험이 저하됩니다. 대신 사용자가 원칙 4와 5에 해당하는 비밀번호를 공개하도록 하고 각각 제어 권한을 부여 하고 선택권을 제공 하도록 하는 것이 좋습니다. 이렇게 하면 사용자가 아무도 보고 있지 않다는 것을 알 때 비밀번호를 공개하도록 선택할 수 있어 오타의 위험이 줄어듭니다.

최신 버전의 Internet Explorer 및 Microsoft Edge는 기본적으로 이 동작을 제공합니다. 자체 솔루션을 만들 것이므로 다음과 같이 CSS를 사용하여 이 기능을 억제해야 합니다.

 input[type=password]::-ms-reveal { display: none; }

먼저 입력 옆에 버튼을 삽입해야 합니다. <button> 요소는 JavaScript로 무엇이든 변경하기 위한 이동 요소여야 합니다. 단, 링크의 목적인 위치 변경은 예외입니다. 클릭하면 password 와 text 사이에서 유형 속성을 전환해야 합니다. "Show"와 "Hide" 사이의 버튼 레이블.

 function PasswordReveal(input) { // store input as a property of the instance // so that it can be referenced in methods // on the prototype this.input = input; this.createButton(); }; PasswordReveal.prototype.createButton = function() { // create a button this.button = $('<button type="button">Show password</button>'); // inject button $(this.input).parent().append(this.button); // listen to the button's click event this.button.on('click', $.proxy(this, 'onButtonClick')); }; PasswordReveal.prototype.onButtonClick = function(e) { // Toggle input type and button text if(this.input.type === 'password') { this.input.type = 'text'; this.button.text('Hide password'); } else { this.input.type = 'password'; this.button.text('Show password'); } };

#### JavaScript 구문 및 아키텍처 참고 사항

JavaScript에는 많은 종류가 있고 구성 요소를 설계하는 다양한 방법이 있으므로 이 책에서 암호 공개 구성 요소를 구성하는 데 사용되는 선택 사항과 앞으로 나올 모든 구성 요소를 살펴보겠습니다.

먼저 생성자를 사용합니다. 생성자는 일반적으로 대문자 대문자로 작성된 함수입니다 — PasswordReveal 이 아니라 passwordReveal . 동일한 코드를 사용하여 구성 요소의 여러 인스턴스를 생성할 수 있도록 하는 new 키워드를 사용하여 초기화됩니다.

 var passwordReveal1 = new PasswordReveal(document.getElementById('input1')); var passwordReveal2 = new PasswordReveal(document.getElementById('input2'));

둘째, 구성 요소의 메서드는 프로토타입에 정의되어 있습니다(예: PasswordReveal.prototype.onButtonClick ). 프로토타입은 동일한 구성 요소의 여러 인스턴스에서 메서드를 공유하는 가장 효과적인 방법입니다.

셋째, jQuery는 요소를 생성 및 검색하고 이벤트를 수신하는 데 사용됩니다. jQuery가 필요하지 않거나 선호되지 않을 수 있지만, 이를 사용한다는 것은 이 책이 브라우저 간 구성 요소의 복잡성이 아닌 양식에 초점을 맞출 수 있음을 의미합니다.

코딩을 조금 하는 디자이너라면 jQuery의 편재성과 낮은 진입 장벽이 도움이 될 것입니다. 마찬가지로 jQuery를 사용하지 않으려는 경우 기본 설정에 맞게 구성 요소를 리팩토링하는 데 문제가 없습니다.

$.proxy 함수의 사용을 눈치채셨을 수도 있습니다. 이것은 jQuery의 Function.prototype.bind 구현입니다. 이 함수를 사용하여 이벤트를 수신하지 않으면 이벤트 핸들러가 요소의 컨텍스트( this )에서 호출됩니다. 위의 예에서 this.button 은 정의되지 않았습니다. 그러나 우리는 this 속성과 메소드에 접근할 수 있도록 대신 비밀번호 공개 객체가 되기를 원합니다.

#### 대체 인터페이스 옵션

위에서 구성한 암호 공개 인터페이스는 "비밀번호 표시"와 "비밀번호 숨기기" 사이에서 버튼 레이블을 전환합니다. 일부 스크린 리더 사용자는 버튼의 레이블이 변경될 때 혼동할 수 있습니다. 사용자는 버튼을 만나면 해당 버튼이 지속되기를 기대합니다. 버튼 은 지속되지만 레이블을 변경하면 그렇지 않은 것처럼 보입니다.

연구 결과 이것이 문제인 경우 두 가지 대안을 시도해 볼 수 있습니다.

먼저 "비밀번호 표시"라는 영구 레이블이 있는 확인란을 사용합니다. 상태는 checked 속성으로 표시됩니다. 스크린 리더 사용자는 "비밀번호 표시, 확인란, 선택됨"(또는 이와 유사한)을 듣게 됩니다. 시력이 있는 사용자는 확인란 체크 표시를 볼 수 있습니다. 이 접근 방식의 문제점은 체크박스가 인터페이스를 제어하는 ​​것이 아니라 데이터를 입력하기 위한 것이라는 점입니다. 일부 사용자는 암호가 시스템에 공개될 것이라고 생각할 수 있습니다.

또는 두 번째로 레이블이 아닌 버튼의 state 를 변경합니다. 화면 판독기 사용자에게 상태를 전달하기 위해 aria-pressed 속성을 true (누른 상태)와 false (누르지 않은 상태) 사이에서 전환할 수 있습니다.

 <button type="button" aria-pressed="true"> Show password </button>

버튼에 초점을 맞추면 화면 판독기가 "비밀번호 표시, 버튼 토글, 눌림"(또는 이와 유사한)이라고 알려줍니다. 시력 사용자의 경우 다음과 같은 속성 선택기를 사용하여 버튼이 눌리거나 눌리지 않은 것처럼 보이도록 스타일을 지정할 수 있습니다.

 [aria-pressed="true"] { box-shadow: inset 0 0 0 0.15rem #000, inset 0.25em 0.25em 0 #fff; }

누르지 않은 스타일과 누르지 않은 스타일이 명확하고 구별되는지 확인하십시오. 그렇지 않으면 시력이 좋은 사용자가 둘 사이의 차이점을 구별하기 어려울 수 있습니다.

### 현미경

레이블은 "비밀번호"가 아닌 "비밀번호 선택"으로 설정됩니다. 후자는 다소 혼란스럽고 사용자에게 이미 소유한 암호를 입력하라는 메시지를 표시할 수 있으며 이는 보안 문제일 수 있습니다. 더 미묘하게는 사용자가 이미 등록되어 있음을 암시하여 인지 장애가 있는 사용자가 대신 로그인하고 있다고 생각할 수 있습니다.

"비밀번호"가 모호한 경우 "비밀번호 선택"이 명확성을 제공합니다.

## 버튼 스타일

버튼이 뭔가요? 우리는 웹 페이지에서 다양한 유형의 구성 요소를 버튼이라고 합니다. 사실, 나는 이미 두 가지 다른 유형의 버튼을 언급하지 않고 다뤘습니다. 이제 해보자.

양식을 제출하는 버튼은 "제출 버튼"이며 일반적으로 <input type="submit"> 또는 <button type="submit"> 로 코딩됩니다. <button> 요소는 내부에 다른 요소를 중첩할 수 있다는 점에서 더 유연합니다. 하지만 그럴 필요는 거의 없습니다. 대부분의 제출 버튼에는 텍스트만 포함되어 있습니다.

참고: 이전 버전의 Internet Explorer에서 <button type="submit"> 이 여러 개 있는 경우 클릭한 버튼에 관계없이 양식은 모든 버튼의 값을 서버에 제출합니다. 어떤 버튼을 클릭했는지 알아야 올바른 조치를 취할 수 있으므로 이 요소를 피해야 합니다.

이전에 논의한 암호 공개 구성 요소와 마찬가지로 JavaScript 경험을 향상시키기 위해 다른 버튼이 인터페이스에 삽입됩니다. 그것도 <button> 이었지만 그 type 은 button ( submit 아님)으로 설정되었습니다.

두 경우 모두 버튼에 대해 가장 먼저 알아야 할 것은 버튼이 링크가 아니라는 것입니다. 링크는 일반적으로 밑줄이 그어지거나(사용자 에이전트 스타일에 따라) 일반 텍스트에서 구분할 수 있도록 특별히 배치됩니다(탐색 모음). 링크 위로 마우스를 가져가면 커서가 포인터로 바뀝니다. 버튼과 달리 링크는 인지된 어포던스가 약하기 때문입니다.

Resilient Web Design 에서 Jeremy Keith는 물질적 정직성에 대해 논의합니다. 그는 이렇게 말합니다. “한 재료를 다른 재료로 대체해서는 안 됩니다. 그렇지 않으면 최종 결과는 기만적입니다.” 링크를 버튼처럼 보이게 하는 것은 실질적으로 부정직합니다. 링크와 버튼은 동일하지 않을 때 동일하다고 사용자에게 알려줍니다.

링크는 버튼이 할 수 없는 일을 할 수 있습니다. 예를 들어 링크를 새 탭에서 열거나 나중에 사용할 수 있도록 북마크에 추가할 수 있습니다. 따라서 버튼은 링크처럼 보이거나 포인터 커서가 있어서는 안 됩니다. 대신, 우리는 버튼이 자연스럽게 강한 인지 어포던스를 갖는 버튼처럼 보이게 만들어야 합니다. 둥근 모서리, 그림자 및 테두리가 있는지 여부는 사용자에게 달려 있지만 관계없이 버튼처럼 보일 것입니다.

버튼은 예를 들어 배경색을 변경하여 호버(및 초점)에 대한 피드백을 계속 제공할 수 있습니다.

### 게재위치

제출 버튼은 일반적으로 양식 하단에 배치됩니다. 대부분의 양식에서 사용자는 위에서 아래로 필드를 작성한 다음 제출합니다. 그러나 버튼을 왼쪽, 오른쪽 또는 중앙에 정렬해야 합니까? 이 질문에 답하기 위해서는 사용자가 자연스럽게 찾을 위치를 생각해야 합니다.

필드 레이블과 양식 컨트롤은 왼쪽(왼쪽에서 오른쪽 읽기 언어)으로 정렬되고 위에서 아래로 실행됩니다. 사용자는 마지막 필드 아래에서 다음 필드를 찾습니다. 그러면 당연히 제출 버튼도 해당 위치에 위치해야 합니다. 왼쪽과 마지막 필드 바로 아래에 있어야 합니다. 또한 오른쪽 정렬 버튼이 화면에서 더 쉽게 사라질 수 있으므로 확대하는 사용자에게 도움이 됩니다.

### 텍스트

버튼의 텍스트는 스타일만큼이나 중요합니다. 텍스트는 취하는 조치를 명시적으로 설명해야 합니다. 그리고 동작이기 때문에 동사여야 합니다. 읽기가 더 빠르기 때문에 가능한 한 적은 수의 단어를 사용하는 것을 목표로 해야 합니다. 그러나 명확성을 희생하여 단어를 제거해서는 안 됩니다.

정확한 단어는 브랜드의 어조와 일치할 수 있지만 명확성과 기이함을 교환하지 마십시오.

간단하고 쉬운 언어는 누구나 이해하기 쉽습니다. 정확한 단어는 서비스 유형에 따라 다릅니다. 등록 양식의 경우 "등록"이 좋지만 서비스에 따라 "가입" 또는 "등록"이 더 적절할 수 있습니다.

## 검증

포괄적이고 간단하며 마찰 없는 등록 환경을 만들기 위한 노력에도 불구하고 인적 오류를 제거할 수는 없습니다. 사람들은 실수를 하고 실수를 했을 때 최대한 쉽게 고칠 수 있도록 해야 합니다.

양식 유효성 검사와 관련하여 고려해야 할 몇 가지 중요한 세부 사항이 있습니다. 피드백을 제공할 시기 선택부터 피드백을 표시하는 방법, 좋은 오류 메시지 작성에 이르기까지 이 모든 사항을 고려해야 합니다.

### HTML5 유효성 검사

HTML5 유효성 검사는 이제 한동안 사용되었습니다. 몇 가지 HTML 속성만 추가하면 지원 브라우저에서 양식이 제출될 때 잘못된 필드를 표시합니다. 지원하지 않는 브라우저는 서버 측 유효성 검사로 대체됩니다.

일반적으로 브라우저가 무료로 제공하는 기능을 사용하는 것이 좋습니다. 브라우저가 더 성능이 좋고 강력하며 액세스하기 쉬운 경우가 많기 때문입니다. 말할 것도 없이, 더 많은 사이트에서 표준 기능을 사용하기 시작하면서 사용자에게 더 친숙해집니다.

HTML5 유효성 검사 지원은 상당히 좋지만 균일하게 구현되지는 않습니다. 예를 들어 required 속성은 처음부터 필드를 잘못된 것으로 표시할 수 있으며 이는 바람직하지 않습니다. Firefox 45.7과 같은 일부 브라우저는 사용자가 상자에 무언가를 입력해도 "이메일 주소를 입력하십시오"라는 오류를 표시하지만, 예를 들어 Chrome에서는 "이메일 주소에 '@'를 포함하십시오."라고 말합니다. 더 도움이 됩니다.

또한 오류가 서버에서 포착되든 클라이언트에서 포착되든 사용자에게 동일한 인터페이스를 제공하고자 합니다. 이러한 이유로 우리는 자체 솔루션을 설계할 것입니다. 가장 먼저 할 일은 HTML5 유효성 검사를 끄는 것입니다. <form novalidate>

### 제출 처리

사용자가 양식을 제출할 때 오류가 있는지 확인해야 합니다. 있는 경우 양식이 서버에 세부 정보를 제출하지 못하도록 해야 합니다.

 function FormValidator(form) { form.on('submit', $.proxy(this, 'onSubmit')); } FormValidator.prototype.onSubmit = function(e) { if(!this.validate()) { e.preventDefault(); // show errors } };

버튼의 클릭 이벤트가 아니라 양식의 제출 이벤트를 수신하고 있습니다. 후자는 포커스가 필드 중 하나에 있을 때 Enter 키를 눌러 사용자가 양식을 제출할 수 없도록 합니다. 이를 암시적 양식 제출 이라고도 합니다.

### 피드백 표시

그것은 모두 오류의 존재를 매우 잘 감지하지만 이 시점에서 사용자는 더 현명하지 않습니다. 업데이트해야 하는 인터페이스의 세 가지 서로 다른 부분이 있습니다. 이제 각각에 대해 이야기하겠습니다.

#### 문서 제목

문서의 <title> 은 웹 페이지에서 스크린 리더가 읽는 첫 번째 부분입니다. 따라서 사용자에게 제출에 문제가 있음을 신속하게 알리는 데 사용할 수 있습니다. 이는 서버 요청 후 페이지를 다시 로드할 때 특히 유용합니다.

JavaScript를 사용하여 클라이언트에서 오류를 포착하여 사용자 경험을 개선하고 있지만 모든 오류를 이런 방식으로 포착할 수 있는 것은 아닙니다. 예를 들어, 이메일 주소가 아직 사용되지 않았는지 확인하는 것은 서버에서만 확인할 수 있습니다. 그리고 어쨌든 JavaScript는 실패하기 쉬우므로 가용성에만 의존할 수 없습니다.

원래 페이지 제목이 "[서비스]에 등록"이라고 표시될 수 있지만 오류가 발생하면 "(2 오류) [서비스]에 등록"(또는 이와 유사한)이라고 읽어야 합니다. 정확한 표현은 다소 의견에 달려 있습니다.

다음 JavaScript는 제목을 업데이트합니다.

 document.title = "(" + this.errors.length + ")" + document.title;

위에서 언급했듯이 이것은 주로 스크린 리더 사용자를 위한 것이지만 포괄적인 디자인의 경우 종종 그러하듯이 한 사용자 집합을 돕는 것은 다른 모든 사람들에게도 도움이 됩니다. 이번에는 업데이트된 제목이 탭에서 알림 역할을 합니다.

오류 요약

제목 요소와 비교하여 오류 요약이 더 눈에 띄며, 이는 시력을 가진 사용자에게 문제가 발생했음을 알려줍니다. 그러나 사용자가 무엇이 잘못되었고 어떻게 수정해야 하는지 이해할 수 있도록 해야 합니다.

페이지 상단에 위치하므로 사용자가 페이지 새로 고침 후 아래로 스크롤할 필요가 없습니다(서버에서 오류가 포착되어야 함). 일반적으로 오류는 빨간색으로 표시됩니다. 그러나 색상에만 의존하면 색맹 사용자를 제외할 수 있습니다. 요약에 주의를 기울이려면 위치, 크기, 텍스트 및 도상도 사용하는 것이 좋습니다.

패널에는 문제를 나타내는 "문제가 있습니다."라는 제목이 있습니다. 그다지 친숙하지 않은 "Error"라는 단어가 표시되지 않습니다. 쇼룸에서 자동차를 구매하기 위해 세부 정보를 작성하다가 실수를 했다고 상상해 보십시오. 영업 사원은 "오류"라고 말하지 않을 것입니다. 실제로 그렇게 말하면 이상할 것입니다.

 <div class="errorSummary" role="group" tabindex="-1" aria-labelledby="errorSummary-heading"> <h2>There's a problem</h2> <ul> <li><a href="#emailaddress">Enter an email address</a></li> <li><a href="#password">The password must contain an uppercase letter</a></li> </ul> </div>

컨테이너에는 인터페이스 요소 집합을 그룹화하는 데 사용되는 group role 이 있습니다(이 경우 제목 및 오류 링크). tabindex 속성은 -1 로 설정되어 JavaScript로 프로그래밍 방식으로 집중할 수 있습니다(양식이 실수로 제출된 경우). 이렇게 하면 오류 요약 패널이 보기로 스크롤됩니다. 그렇지 않으면 제출할 때 인터페이스가 응답하지 않고 깨져 보입니다.

참고: tabindex="0" 을 사용하면 탭 키를 통해 영구적으로 초점을 맞출 수 있음을 의미합니다. 이는 2.4.3 초점 순서 WCAG 실패입니다. 사용자가 무언가를 탭할 수 있다면 실제로 무언가를 할 것이라고 기대합니다.

 FormValidator.prototype.showSummary = function () { // ... this.summary.focus(); };

그 아래에 오류 링크 목록이 있습니다. 링크를 클릭하면 사용자가 양식으로 빠르게 이동할 수 있도록 잘못된 필드에 포커스가 설정됩니다. 링크의 href 속성은 컨트롤의 id로 설정되며 일부 브라우저에서는 포커스를 설정하기에 충분합니다. 그러나 다른 브라우저에서 링크를 클릭하면 초점을 맞추지 않고 보기로 입력을 스크롤합니다. 이 문제를 해결하기 위해 명시적으로 입력에 초점을 맞출 수 있습니다.

 FormValidator.prototype.onErrorClick = function(e) { e.preventDefault(); var href = e.target.href; var id = href.substring(href.indexOf("#"), href.length); $(id).focus(); };

오류가 없으면 요약 패널을 숨겨야 합니다. 이렇게 하면 페이지에 요약 패널이 하나만 있고 오류가 클라이언트에 의해 렌더링되는지 서버에 의해 렌더링되는지 여부에 관계없이 동일한 위치에 일관되게 표시됩니다. 패널을 숨기려면 hidden 클래스를 추가해야 합니다.

 <div class="errorSummary hidden" ...></div>

 .hidden { display: none; }

참고: hidden 속성/속성을 사용하여 요소의 가시성을 토글할 수 있지만 지원은 적습니다. 포용적 디자인은 사람들을 배제할 것 같지 않은 결정을 내리는 것입니다. 클래스를 사용하는 것은 이 철학과 일치합니다.

#### 인라인 오류

필드 바로 위에 관련 오류 메시지를 배치해야 합니다. 이렇게 하면 사용자가 오류 메시지를 확인하기 위해 페이지를 위아래로 스크롤하지 않아도 되며 양식 아래로 계속 이동하게 됩니다. 메시지가 필드 아래에 있는 경우 브라우저 자동 완성 패널이나 화면 키보드에 의해 메시지가 가려질 가능성이 높아집니다.

 <div class="field"> <label for="blah"> <span class="field-error"> <svg width="1.5em" height="1.5em"><use xmlns:xlink="https://www.w3.org/1999/xlink" xlink:href="#warning-icon"></use></svg> Enter your email address. </span> <span class="field-error">Enter an email address</span> </label> </div>

앞서 언급한 힌트 패턴과 마찬가지로 레이블 내부에 오류 메시지가 삽입됩니다. 필드에 초점이 맞춰지면 스크린 리더 사용자는 컨텍스트에서 메시지를 들을 수 있으므로 요약을 참조하지 않고도 양식을 자유롭게 이동할 수 있습니다.

오류 메시지는 빨간색이며 SVG 경고 아이콘을 사용하여 사용자의 주의를 끕니다. 오류를 표시하기 위해 색상 변경만 사용했다면 색맹 사용자는 제외됩니다. 따라서 이것은 시력이 좋은 사용자에게 정말 잘 작동합니다. 하지만 스크린 리더 사용자는 어떻습니까?

시력이 있는 사용자와 그렇지 않은 사용자 모두에게 동등한 경험을 제공하기 위해 잘 지원되는 aria-invalid 속성을 사용할 수 있습니다. 사용자가 입력에 초점을 맞추면 이제 스크린 리더에서 "유효하지 않음"(또는 이와 유사한 것)을 알립니다.

 <input aria-inval>

참고: 등록 양식은 텍스트 입력으로만 구성됩니다. 3장, "항공편 예약 양식"에서 라디오 버튼과 같은 필드 그룹에 액세스할 수 있는 오류를 삽입하는 방법을 살펴보겠습니다.

### 양식 다시 제출

두 번째로 양식을 제출할 때 기존 오류를 보기에서 지워야 합니다. 그렇지 않으면 사용자에게 중복 오류가 표시될 수 있습니다.

 FormValidator.prototype.onSubmit = function(e) { this.resetPageTitle(); this.resetSummaryPanel(); this.removeInlineErrors(); if(!this.validate()) { e.preventDefault(); this.updatePageTitle(); this.showSummaryPanel(); this.showInlineErrors(); } };

### 초기화

FormValidator 구성 요소 정의를 마쳤으므로 이제 초기화할 준비가 되었습니다. FormValidator 의 인스턴스를 생성하려면 첫 번째 매개변수로 양식 요소를 전달해야 합니다.

 var validator = new FormValidator(document.getElementById('registration'));

예를 들어 이메일 필드의 유효성을 검사하려면 addValidator() 메서드를 호출합니다.

 validator.addValidator('email', [{ method: function(field) { return field.value.trim().length > 0; }, message: 'Enter your email address.' },{ method: function(field) { return (field.value.indexOf('@') > -1); }, message: 'Enter the 'at' symbol in the email address.' }]);

첫 번째 매개변수는 컨트롤의 name 이고 두 번째 매개변수는 규칙 객체의 배열입니다. 각 규칙에는 method 와 message 의 두 가지 속성이 있습니다. method 는 true 또는 false 를 반환하기 위해 다양한 조건을 테스트하는 함수입니다. False는 필드를 오류 상태로 전환하며, 이는 앞에서 설명한 대로 인터페이스를 오류로 채우는 데 사용됩니다.

#### 사소한 실수 용서

Design of Everyday Things 에서 Don Norman은 오류를 위한 디자인에 대해 이야기합니다. 그는 사람들이 대화하는 방식에 대해 다음과 같이 말합니다.

“누군가가 우리가 거짓이라고 믿는 말을 하면 질문하고 토론합니다. 경고 신호를 보내지 않습니다. 우리는 경고하지 않습니다. 우리는 오류 메시지를 제공하지 않습니다. […] 두 친구 사이의 일반적인 대화에서 잘못된 표현은 실제 의미에 대한 근사치인 정상적인 것으로 간주됩니다.”

인간과 달리 기계는 대부분의 행동의 의미를 결정할 만큼 지능적이지 않지만, 필요 이상으로 실수를 훨씬 덜 용서하는 경우가 많습니다. Jared Spool은 "Is Design Metrically Opposed?"에서 이에 대해 농담을 합니다. (약 42분):

"전화번호를 가져와서 모든 대시, 괄호, 공백을 제거하려면 한 줄의 코드가 필요하고, 당신이 그것들을 남겼던 오류 메시지를 작성하는 데는 10줄의 코드가 필요합니다."

addValidator 메소드(위 참조)는 사소한 실수를 용서하도록 유효성 검사 규칙을 설계하는 방법을 보여줍니다. 예를 들어 첫 번째 규칙은 길이를 확인하기 전에 값을 트리밍하여 사용자의 부담을 줄입니다.

### 라이브 인라인 검증

실시간 인라인 유효성 검사는 사용자가 입력할 때 또는 필드를 떠날 때( onblur ) 피드백을 제공합니다. 실시간 인라인 유효성 검사가 정확성을 향상시키고 긴 형식의 완료 시간을 줄인다는 몇 가지 증거가 있습니다. 이것은 부분적으로 사용자의 마음에 현장의 요구 사항이 신선할 때 사용자에게 피드백을 제공하는 것과 관련이 있습니다. 그러나 라이브 인라인 유효성 검사(또는 줄여서 라이브 유효성 검사)에는 몇 가지 문제가 있습니다.

특정 수의 문자가 필요한 항목의 경우 첫 번째 키 입력은 항상 잘못된 항목을 구성합니다. 이는 사용자가 일찍 중단되어 정보 입력에서 수정으로 정신적 컨텍스트를 전환할 수 있음을 의미합니다.

또는 오류를 표시하기 전에 사용자가 충분한 문자를 입력할 때까지 기다릴 수 있습니다. 그러나 이것은 사용자가 올바른 값을 입력한 후에만 피드백을 받는다는 것을 의미합니다. 이는 다소 무의미합니다.

사용자가 필드를 떠날 때까지 기다릴 수 있지만( onblur ), 사용자가 다음 필드에 대해 정신적으로 준비(그리고 종종 입력을 시작)했기 때문에 이것은 너무 늦었습니다. 또한 일부 사용자는 양식을 사용할 때 창을 전환하거나 암호 관리자를 사용합니다. 그렇게 하면 흐림 이벤트가 트리거되어 사용자가 완료되기 전에 오류가 표시됩니다. 모두 매우 실망스럽습니다.

페이지를 새로 고치지 않고 사용자에게 피드백을 제공하는 데 문제가 없음을 기억하십시오. 오류 메시지를 인라인(필드 옆)에 넣는 데도 문제가 없습니다. 이미 완료했습니다. 실시간 피드백의 문제는 너무 일찍 또는 너무 늦게 사용자를 방해하여 종종 혼란스러운 경험을 초래한다는 것입니다.

사용자에게 오류가 자주 표시되는 경우 다른 곳에 문제가 있을 수 있습니다. 양식을 줄이고 더 나은 지침을 제공하는 데 중점을 둡니다(좋은 레이블 및 힌트 텍스트). 이런 식으로 사용자는 이상한 오류 이상을 볼 수 없습니다. 다음 장에서 더 긴 형식을 살펴보겠습니다.

### 체크리스트 확인 패턴

실시간 유효성 검사의 변형에는 사용자가 입력할 때 규칙을 확인(완료로 표시)하는 것이 포함됩니다. 이것은 라이브 유효성 검사보다 덜 침습적이지만 모든 유형의 필드에 적합하지는 않습니다. 다음은 비밀번호 필드에 이 기술을 사용하는 MailChimp 가입 양식의 예입니다.

필드 위에 규칙을 놓아야 합니다. 그렇지 않으면 화면 키보드가 피드백을 가릴 수 있습니다. 결과적으로 사용자는 입력을 중지하고 키보드를 숨긴 다음 피드백을 확인할 수 있습니다.

### 제출 버튼 비활성화에 대한 참고 사항

일부 양식은 모든 필드가 유효해질 때까지 제출 버튼을 비활성화하도록 설계되었습니다. 여기에는 몇 가지 문제가 있습니다.

첫째, 사용자는 자신의 항목에 실제로 무엇이 잘못되었는지 궁금해합니다. 둘째, 비활성화된 버튼은 초점을 맞출 수 없기 때문에 Tab 키를 사용하여 탐색하는 시각 장애인 사용자가 버튼을 찾기가 어렵습니다. 셋째, 비활성화된 버튼은 회색으로 표시되어 읽기 어렵습니다.

우리는 사용자에게 명확한 피드백을 제공하고 있으므로 사용자가 예상할 때 어쨌든 버튼을 비활성화하여 사용자로부터 제어권을 빼앗을 정당한 이유가 없습니다.

### 좋은 오류 메시지 만들기

내용보다 중요한 것은 없습니다. 사용자는 디자인을 즐기기 위해 웹사이트를 방문하지 않습니다. 서비스 이용의 내용이나 결과를 즐기러 옵니다.

오류 메시지를 작성하는 데 사용되는 단어를 무시한다면 가장 신중하고 포괄적이며 아름답게 디자인된 경험도 아무 소용이 없습니다. 한 연구에 따르면 사용자 지정 오류 메시지를 표시하면 전환이 0.5% 증가하여 연간 수익이 £250,000 이상인 것으로 나타났습니다.

“콘텐츠는 사용자 경험입니다.”
— 지니 레디쉬

레이블, 힌트 및 기타 콘텐츠와 마찬가지로 좋은 오류 메시지는 가능한 한 적은 단어로 명확성을 제공합니다. 일반적으로 우리는 콘텐츠를 기반으로 인터페이스 디자인을 추진해야 합니다. 그 반대는 아닙니다. 그러나 이 경우 오류 메시지를 표시하는 방법과 이유를 이해하면 단어 디자인에 영향을 줍니다. 이것이 Jared Spool이 "콘텐츠와 디자인은 떼려야 뗄 수 없는 작업 파트너"라고 말한 이유입니다.

화면 상단과 필드 옆의 요약에 메시지가 표시됩니다. 동일한 메시지의 두 가지 버전을 유지하는 것은 설득력이 없는 이익을 얻기 위해 열심히 판매하는 것입니다. 대신 두 위치에서 모두 작동하는 오류 메시지를 디자인하십시오. "'at' 기호 입력"이 이해되려면 필드 레이블의 컨텍스트가 필요합니다. "이메일 주소에는 'at' 기호가 필요합니다."는 두 위치 모두에서 잘 작동합니다.

각 오류 메시지를 "제발"로 시작하는 것과 같은 유쾌한 말을 피하십시오. 한편으로 이것은 공손해 보입니다. 다른 한편, 그것은 방해가 되고 선택을 의미합니다.

어떤 접근 방식을 취하든 콘텐츠의 특성으로 인해 약간의 반복이 있을 것입니다. 그리고 테스트에는 일반적으로 정보를 전혀 입력하지 않고 양식을 제출하는 것이 포함됩니다. 이것은 반복을 눈에 띄게 명확하게 만들어 우리를 뒤집을 수 있습니다. 그러나 얼마나 자주 이런 경우가 있습니까? 대부분의 사용자는 인터페이스를 깨려고 하지 않습니다.

다른 오류에는 다른 형식이 필요합니다. "이름을 입력하십시오"와 같은 지시는 자연스럽습니다. 그러나 "이름은 35자 이하로 입력하십시오."는 "이름은 35자 이하여야 합니다."와 같은 설명보다 길고 장황하며 덜 자연스럽습니다.

체크리스트는 다음과 같습니다.

• 간결해야 합니다. 필요한 것보다 더 많은 단어를 사용하지 마십시오. 그러나 명확성을 희생하면서 단어를 생략하지 마십시오.
• 일관성을 유지하십시오. 같은 어조, 같은 단어, 같은 구두점을 사용하십시오.
• 구체적이어야 합니다. 왜 문제가 발생했는지 안다면 그렇게 말하십시오. "이메일이 잘못되었습니다." 모호하고 사용자에게 부담을 줍니다. "이메일에는 'at' 기호가 필요합니다."는 분명합니다.
• 인간이 되십시오. 전문 용어를 피하십시오. 무효, 금지 및 필수와 같은 단어를 사용하지 마십시오.
• 평범한 언어를 사용하십시오. 오류 메시지는 브랜드의 유머러스한 어조를 홍보할 기회가 아닙니다.
• 능동태를 ​​사용하십시오. 오류가 지침이고 사용자에게 무엇을 해야 하는지 알려주는 경우. 예를 들어, "이름을 입력해야 합니다."가 아니라 "이름을 입력하세요."
• 사용자를 비난하지 마십시오. 무엇이 잘못되었고 어떻게 고칠 수 있는지 알려주십시오.

## 요약

이 장에서 우리는 단순한 등록 양식 이상으로 적용할 수 있는 몇 가지 기본적인 양식 디자인 문제를 해결했습니다. 많은 면에서 이 장은 우리가 해야 할 일만큼 하지 말아야 할 일에 대해서도 많이 다루었습니다. 우리가 포함하는 필드의 수를 줄이는 데 집중하기 위해 참신하고 인공적인 공간 절약 패턴을 피함으로써 우리는 여러 사용성 실패를 피하면서 동시에 양식을 더 즐겁게 만듭니다.

### 피해야 할 사항

• 레이블 및 힌트 텍스트를 저장하기 위한 메커니즘으로 placeholder 속성을 사용합니다.
• 잘못된 입력 유형을 사용합니다.
• 스타일 버튼과 링크는 동일합니다.
• 사용자가 입력할 때 필드 유효성 검사.
• 제출 버튼 비활성화.
• 복잡한 전문 용어와 브랜드 영향을 받는 현미경 사용.

그리고 그게 다야. Form Design Patterns 의 첫 번째 장이 마음에 든다면 바로 책을 받을 수 있습니다. 즐거운 독서!