DDODDO LAB

공공기관 검수 대응 가이드공공기관 고도화에서폼 영역은 접근성 QA의 핵심 체크 대상이다.특히 자주 지적되는 항목:필수 입력 표시가 시각적으로만 존재에러 메시지가 입력창과 연결되지 않음포커스 이동 미흡색상으로만 상태 구분placeholder를 label처럼 사용이번 글은실무에서 바로 적용 가능한 규칙 중심으로 정리한다. 1. 필수 입력 표시 규칙❌ 자주 틀리는 방식이름 * 문제:*가 시각적으로만 의미 있음스크린리더는 필수인지 모름✅ 올바른 방식 이름 * 핵심 포인트required 속성 사용aria-required="true" 명시별표는 aria-hidden 처리필수 안내 문구도 필요폼 상단에표시는 필수 입력 항목입니다. 같은 안내 문구를 제공하면 더 좋다.2. 에러 메시지 구조 규칙❌ 잘못된 구조 ..

공공기관 고도화 대응 정리공공기관 프로젝트에서테이블은 QA에서 가장 많이 걸리는 영역 중 하나다.특히 자주 지적되는 항목이:caption 누락scope 잘못 사용th/td 구조 오류의미 없는 table 사용이번 글에서는실무에서 바로 적용 가능한 기준으로 정리한다. 1. caption은 왜 필요한가?caption은 단순 제목이 아니다.스크린리더는테이블을 읽기 전에 caption을 먼저 읽는다.즉,“이 테이블이 무엇을 설명하는지”를 알려주는 장치다. ❌ 잘못된 예 이름 부서 → 스크린리더는“테이블 시작, 2열 10행” 이런 식으로만 읽는다. ✅ 올바른 예 직원 정보 목록 이름 부서 caption은 화면에 보여도 되고,숨겨도 된다 🔹 화면에 보이지..

공공기관 고도화 실전: 시작 전에 반드시 해야 할 5가지공공기관 고도화 프로젝트는“디자인 나오면 코딩 시작”이 아니다.시작 전에 구조를 정리하지 않으면프로젝트 중반부터 무너진다.실제 실무 기준으로 정리한다. 1. 기존 구조부터 해부하라고도화인데기존 구조를 안 보면 100% 문제 난다.확인해야 할 것:CSS / SCSS 혼용 여부공통 include 방식레이아웃 고정폭인지 유동폭인지v2 / v3 병행 폴더 존재 여부중복 컴포넌트 존재 여부>> 기존 공통 파일을 먼저 정리해야 한다. 2. 반응형 전략을 통일하라공공기관은 대부분 PC First 구조다.확인할 것:min-width / max-width 혼재 여부실제 브레이크포인트 값1024 / 768 기준 적용 방식접근성 대응 방식전략 통일 없이 작업하면파일마..

공공기관 웹사이트가 PC First 구조로 설계되는 이유 분석. 접근성, 인증, 레거시 유지보수 관점에서 반응형 전략 정리. 왜 공공기관 사이트는 아직도 PC First일까?최근 프로젝트를 진행하며여러 공공기관 사이트의 CSS 구조를 분석해봤습니다. 의외로 많은 사이트가Mobile First가 아닌 PC First 구조로 되어 있었습니다. 왜일까요? 단순히 “구식이라서”는 아닙니다. 1. 인증 및 보안 모듈이 PC 환경 기준공공기관은공동인증서행정 시스템 연계내부 업무 시스템등이 PC 환경 기준으로 설계되어 있습니다. 즉,주 사용 환경이 여전히 데스크톱 중심입니다. 그래서 기본 CSS가 PC 레이아웃이고,모바일은 보조 레이어로 처리합니다. 2. 접근성 검사 기준이 PC 화면 중심웹 접근성 인증 과정에서..

시맨틱 마크업, 왜 중요할까?시맨틱 마크업(Semantic Markup)은 단순히 웹페이지를 "보이게" 만드는 것이 아닌, 의미를 전달하기 위한 웹 퍼블리싱의 기본입니다. 와 만으로도 화면을 꾸밀 수 있지만, 그것만으로는 콘텐츠의 구조나 의도를 사용자나 보조 기술(스크린리더 등)이 이해하기 어렵습니다.예를 들어, , , , 와 같은 HTML5 시맨틱 태그는 콘텐츠의 역할과 흐름을 명확히 드러냅니다. 특히 접근성(A11y) 관점에서는 시맨틱 마크업이 사용자의 맥락 이해에 큰 도움을 주며, 검색 엔진 최적화(SEO)에도 긍정적인 영향을 미칩니다.하지만 퍼블리싱 실무에서는 시간 제약, 반복적인 구조, 협업 부재로 인해 시맨틱 마크업이 생략되거나 단순화되는 경우가 많습니다. 바로 이 지점에서 GPT와 같은 AI..

스크린리더 테스트 없이 GPT로 접근성 검증하기 접근성 검증, 왜 어렵고 시간이 걸릴까?웹 접근성을 구현하는 것도 어렵지만, 검증하는 과정은 더 복잡하고 까다롭습니다. 특히 시각장애인을 위한 스크린리더(예: NVDA, VoiceOver)를 사용해 직접 테스트하려면 다음과 같은 제약이 존재합니다:스크린리더 환경 구축: Windows 또는 macOS에 별도 프로그램 설치학습 필요: 키보드 명령어와 스크린리더 작동 방식 이해 필요테스트 시간: 매 페이지마다 일일이 확인해야 하므로 생산성 저하이러한 이유로 실제 현업에서도 스크린리더 테스트는 QA 단계에서 일부만 진행하거나 생략되는 경우가 많습니다. 그러나 이런 방식은 애드센스 승인 시 주요 장애 요인이 될 수 있고, 법적 접근성 기준을 만족하지 못할 가능성도..