DDODDO LAB

깨지지 않는 관리자 화면 만드는 방법 반응형 작업에서가장 난이도가 높은 요소는 테이블이다.모바일에서 가로 스크롤 발생컬럼이 줄어들며 의미 손실버튼이 밀림정렬이 깨짐테이블은 단순히 줄이는 게 아니라전략적으로 설계해야 한다. 1. 테이블은 줄이는 게 아니라 “방식”을 바꿔야 한다많은 사람들이 이렇게 생각한다.“모바일에서 width:100%면 되겠지?”아니다. 테이블은 화면 크기에 따라표현 방식을 바꾸는 것이 핵심이다.2. 반응형 테이블 3가지 2-1. 가로 스크롤 유지 (가장 안전)/* CSS */.table-wrap { overflow-x: auto;}/* HTML */ ... 장점구조 유지접근성 안전관리자 화면에 적합단점모바일 UX는 다소 불편공공기관 관리자 화면은이 방식이 가장 현실적이..

공공기관 고도화 프로젝트를 하다 보면 이런 상황이 나온다.동일한 구조의 사이트 5~9개공통 소스는 공유일부는 별도 관리기존 레거시는 유지신규 레이아웃은 전면 개편이때 디렉토리 구조를 잘못 잡으면중반부터 수정 범위가 통제되지 않는다.고도화의 핵심은 “코딩”이 아니라구조 설계다. 1. 가장 많이 하는 실수❌ 기존 폴더 안에 그냥 덮어쓰기❌ v2, v3를 섞어 쓰기❌ 사이트별로 공통 파일을 복사해서 관리이렇게 되면:공통 수정 시 9번 수정QA 반영 누락배포 충돌유지보수 지옥 2. 기본 전략: “공통과 개별을 분리하라”여러 사이트 고도화 시폴더는 크게 3단계로 나누는 것이 안전하다./common /site-a /site-b /site-c 추천 구조 예시/assets /common /css ..

브레이크포인트 1024 / 768 구조 실전 적용 가이드공공기관 고도화 프로젝트를 들어가면가장 먼저 마주치는 혼란이 있다.“브레이크포인트가 제각각이다.” 어떤 페이지는 1200,어떤 곳은 1024,어떤 파일은 768,심지어 min/max가 섞여 있다. 이 상태에서 작업을 시작하면프로젝트 중반부터 유지보수가 무너진다.고도화의 핵심은 통일이다. 1. 왜 공공기관은 1024 / 768이 많은가?대부분 구조는 이렇게 되어 있다.PC 기준: 1024px 이상태블릿: 768px ~ 1023px모바일: 768px 이하이유는 단순하다.과거 PC 해상도 기준이 1024 중심행정 업무는 PC 사용 비율 높음접근성 인증 기준 대응내부 행정망 해상도 환경 고려즉, 모바일 퍼스트라기보다PC 안정성 중심 구조다. 2. 브..

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

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

공통 컴포넌트 설계 순서 (버튼/테이블/폼 우선순위)(버튼/테이블/폼 우선순위)고도화 프로젝트에서 공통 컴포넌트를 “예쁘게” 만들기보다 중요한 건 하나다.먼저 만들면 손이 덜 가는 것부터 만든다. 특히 공공기관/관리자 화면은 테이블·폼·버튼이 반복되기 때문에설계 순서가 곧 일정이다. 왜 “순서”가 중요한가? 공통을 늦게 잡으면 이런 일이 생긴다.페이지 20개 만든 뒤 버튼 스타일 전체 수정테이블 줄 간격/정렬 규칙이 페이지마다 달라짐폼 요소(인풋/셀렉트)만 QA 때 전부 걸림결국 “공통 반영”으로 재작업이 발생고도화에서 공통은초반에 고정해야 한다. 결론: 추천 설계 순서1) 버튼 (Button)2) 폼 (Form: input/select/checkbox/radio)3) 테이블 (Table)4) 상태..