<textarea> — 폼 태그 도감

올바른 사용

label과 짝

rows·cols로 기본 크기

maxLength로 길이 제한

자동 리사이즈는 CSS field-sizing 또는 JS

댓글 입력

<label for="comment">댓글</label>
<textarea
  id="comment"
  name="comment"
  rows="4"
  maxLength="500"
  placeholder="댓글을 입력하세요"
  required
></textarea>

rows로 기본 높이, maxLength로 글자 수 제한.

자동 리사이즈 (모던 CSS)

<textarea
  id="msg"
  style={{ fieldSizing: 'content' }}
></textarea>

CSS field-sizing 속성으로 native 자동 리사이즈 (Chrome 123+).

자주 보는 안티패턴

label 누락

rows=1로 input처럼 — 시각만 한 줄

고정 size로 모바일 깨짐

자동 리사이즈 직접 구현하다가 a11y 깨짐

rows=1로 input 흉내

<textarea rows="1" />

시각은 input 같지만 Enter가 줄바꿈. 사용자 헷갈림 — input을 쓸 것.

label 없는 textarea

<textarea placeholder="메시지" />

스크린리더가 "편집 가능"만. 시리즈

해설

여러 줄 텍스트 입력의 표준 컨트롤. input은 단일 줄, textarea는 Enter 키로 줄바꿈되는 다중 줄. 댓글, 문의 메시지, 긴 답변에 사용.

SEO 관점에서 textarea 자체가 SEO에 직접 영향은 적다. 다만 댓글 시스템·문의 폼이 있는 페이지는 사용자 engagement 신호가 있어 간접 작용.

GEO 관점에서 AI 에이전트가 긴 메시지 작성이 필요한 작업(문의 보내기, 댓글 달기)에서 textarea를 인식. 일반 input과 구분되어 어떤 종류의 입력인지 명확.

A11y 관점에서 스크린리더가 textarea 진입 시 "여러 줄 편집"으로 발화. 사용자는 Enter가 줄바꿈임을 인지하고 입력. input의 "편집"과 명확히 구분되어 — Enter로 제출되지 않음을 알 수 있다.

자주 보는 안티패턴: label 누락(시리즈 #2 — 라벨은 textarea에도 필수), rows="1"로 input 흉내(시각은 input 같지만 Enter가 줄바꿈 — 사용자가 왜 제출이 안 되지?로 혼란), 고정 size로 모바일 깨짐(rows 대신 CSS height로 조정 권장), 자동 리사이즈를 JS로 onInput 처리하다 a11y 깨짐(스크롤·포커스 위치 어긋남).

자동 리사이즈 — 모던 CSS field-sizing: content로 native 자동 리사이즈 가능(Chrome 123+, 점진적 도입). 이전에는 JS로 scrollHeight를 측정해 height를 조정하는 패턴. JS 패턴은 onChange·onInput과 결합해야 하고, IME(한글 조합) 중에 깜빡임 같은 미세 이슈가 있다. CSS 방식이 더 안전.

rows와 cols 속성 — 기본 크기 지정. rows는 줄 수, cols는 한 줄 글자 수. 다만 반응형 디자인에서는 CSS width/height로 제어가 더 자유롭다. rows는 최소 높이로 두고 CSS overflow로 처리.

maxLength — 글자 수 제한. native로 자동 제한 + 시각 카운터("450/500자")는 별도 구현. 카운터를 aria-live="polite"로 띄우면 스크린리더 사용자도 남은 글자 수를 인지(시리즈 #15 live region).

코드 입력 textarea — 코드 에디터 UI를 textarea로 만드는 경우(GitHub 댓글의 마크다운 입력 등). 시리즈에서 다룬 code 시맨틱과는 별개 — textarea는 사용자 입력이므로 일반 textarea, 결과 표시는 pre+code.

SEO·GEO·AEO·A11y 4축에서의 의미

SEO

GEO

AEO

A11y

올바른 사용

자주 보는 안티패턴

해설