ИЗЗИДА — подробен преглед на сайта

UI/UX, визуален дизайн, accessibility, публична security/privacy конфигурация и подготовка за публикуване. Снимка на състоянието към 21 октомври 2026 г. Обект: build.izzida.com.

1. Общата ми оценка

Сайтът има добра основа и не бих го започвал отначало. Има разпознаваема визуална посока, достатъчно проекти за смислено портфолио и ясно предложение: строителство и интериорен дизайн в Бургас. Топлите неутрални цветове, големите заглавия и интериорната фотография работят заедно. Това не изглежда като случайно събрани страници.

Но има разлика между „изглежда готов“ и „води уверено до запитване“. В момента най-важните пропуски са в тази разлика: основен бутон обещава портфолио, но отваря един проект; имената на избраните проекти изчезват без hover; услугите водят до каталози, а case studies не завършват с убедителна следваща стъпка. Отделно има измерим проблем с контраста и няколко разумни security hardening задачи.

Моят приоритет е: по-ясен път за клиента, четимост, единни компоненти и реално съдържание — не още анимации и не пълно пренаписване. Няма доказани conversion загуби; оценката за влиянието върху запитванията е експертна преценка, не analytics резултат.

Регистърът запазва UX-01–UX-13 и SEC-01–SEC-05 и добавя VIS-01. UX-12 е обединен със SEC-01, а не броен повторно. Получават се 18 отделни теми: 5 Medium, 12 Low и 1 Informational. Това са приоритети за работа, не 18 доказани уязвимости. Цялостната сигурност остава UNKNOWN: публичният преглед не е pentest или разрешение за production.

2. Какво си струва да се запази

Първият екран на началната страница има ясна йерархия: име, география, голямо обещание, кратко пояснение и две действия. На mobile текстът остава четим и бутоните са подредени един под друг. Снимката носи контекст, вместо да е произволен декоративен фон. Моето визуално предпочитание е overlay-ят да остане достатъчно силен за текста, но да се пробва малко по-светла композиция, която показва повече от интериора. Това не е измерен contrast defect върху снимката.

Общите header и footer, Inter за body и Oswald за headings създават разпознаваемост. „Как работим“ е полезна страница: има процес, примери и реални въпроси за бюджет, срокове и организация. Контактите не са скрити — публикувани са телефон, имейл, адрес и работно време.

Има и добри interaction решения. Skip link работи. Mobile drawer задържа Tab focus вътре и Escape връща focus към hamburger. Галерията на „Апартамент Лазур“ вече има работещ keyboard lightbox: Enter отваря, ArrowRight сменя снимката, Escape затваря. На разгледания mobile кадър изображението е голямо, а Close и стрелките са отделени от него. Не трябва да се „добавя lightbox“, а да се запази работещият.

3. Първо: ясна навигация и път до запитване

UX-02 · Medium — основният CTA обещава повече, отколкото отваря

На началната „Разгледайте проектите“ води към „Апартамент Лазур“, не към портфолиото. Destination е потвърден с HTTP 200 и H1 на конкретния проект. Това е разминаване между обещание и резултат, не broken link.

Поправката е малка: или бутонът води към всички проекти, или се казва „Вижте апартамент Лазур“. Бих избрал първото. Приемане: еднакво правилно поведение на desktop/mobile и проверка на EN/RU еквивалентите.

VIS-01 · Low — имената на featured проектите са скрити без hover

В секцията „Нашата работа“ на началната виждам снимки без видими имена и на desktop, и на mobile. В портфолиото имената са видими върху изображенията. Запазеният публичен CSS потвърждава разликата: .izz-card-cap започва с opacity:0, а правилото за показване е върху :hover. Текстовете съществуват в DOM; не твърдя, че links са без accessible names.

Посетителят трябва да разпознава обекта по снимката, преди да реши да отвори. Бих направил заглавието постоянно видимо, с дискретен gradient или caption под снимката; hover да е допълнение, не условие за основната информация. Приемане: името се вижда без взаимодействие при 390px и 1440px; keyboard focus и реален touch тест не губят заглавието или навигацията. Доказателства: кадри V03/V04/V05 в приложението и запазения CSS.

UX-03 · Medium — услугата и портфолиото изпълняват различни задачи

„Ремонти“, „Груб строеж“, „Фасади“ и „Екстериорни решения“ във footer водят към една и съща страница „Строителство“, без section anchor. Там има списък с 20 обекта. „Интериорни проекти“ показва 7. Примерите са полезни, но не отговарят достатъчно ясно на „какво точно включва вашата услуга?“.

Не са нужни веднага десетки landing pages. Добавете кратък обхват, ограничения, начин на работа, подходящи примери и контакт за съответната услуга. Разграничете „Услуги“ от „Портфолио“. Приемане: човек, избрал „Фасади“, стига до конкретна информация за фасади, а не трябва сам да търси такава сред обектите.

UX-04 · Medium — снимките имат нужда от по-силен case study

В проверените 5 BG проекта и един EN проект има галерии и кратки описания, но липсва project-specific inquiry CTA в края. „Апартамент Лазур“ всъщност дава полезен обхват — преразпределение, осветление, кухня и обзавеждане. Не е честно да се нарече празна страница. Но след дългата mobile галерия следва предимно навигация към друг проект, не покана за разговор.

Бих подредил приоритетните обекти като „Задача → Решение → Нашето участие → Резултат“, с проверени площ, година и срок, когато са публикуеми. Завършекът: „Имате подобен проект? Обсъдете го с нас“ и „Всички проекти“. Не измисляйте бюджети, резултати или отзиви. Приемане: всеки приоритетен case study има конкретен контекст и очевиден следващ ход; това не се обобщава автоматично за всички 27 BG проекта.

UX-11 · Low — mailto е валиден избор, но го кажете предварително

„Свържете се с нас“ в hero и „Изпратете запитване“ на „Контакти“ са mailto links, не web inquiry form. mailto отваря имейл програмата на потребителя; поведението зависи от устройството и настройките му.[7] Това не означава, че контактът е счупен.

По-ясно е „Пишете ни по имейл“, с копируем адрес и подсказка: тип обект, населено място, приблизителна площ, желан срок. Web форма е опция, не задължителна функционалност. Ако се добави, заслужава отделен backend/security/privacy тест. Приемане: човек без настроен mail handler пак разбира къде и какво да изпрати. Обещанието за отговор „в рамките на работния ден“ трябва да бъде потвърдено и уточнено за вечер/уикенд.

UX-06 · Low — не изпращайте към бъдещ инструмент като към готов

От „Как работим“ „Към калкулаторите“ отваря страница с четири карти „Очаквайте скоро“, без calculation inputs. Статусът е честно обяснен след клик, но очакването вече е създадено. Заглавието „Как да четете резултата“ допълнително говори за резултат, който още не може да бъде получен.

Преди готовността бих заменил входния CTA с „Как се определя цената“ към действителното обяснение или „Калкулатори — скоро“. Приемане: още от линка е ясно дали има работещ инструмент.

4. Визуален дизайн: една посока, но няколко набора правила

Тук отделям измерените разлики от личната си дизайнерска оценка. Различен hero и различни card types са нормални; целта не е всички блокове да изглеждат еднакво.

UX-05 · Low — едно действие, две различни семейства бутони

На началната долното „Изпратете запитване“ е тъмно, с 14.4px текст, квадратни ъгли и височина около 50.64px. На „Контакти“ същият текст е върху златист theme button: 18px, radius 3px, височина около 45.17px. Facebook secondary е тъмен outline долу на home, но светъл златист текст върху бяло на contact. Разликата се вижда и е потвърдена с computed styles.

Бих оставил един Button component с primary, secondary и text variants и изрични dark/light states. Приемане: еднакво действие има еднаква визуална роля, type, padding, radius и focus правила на home/contact/process. Contrast дефектът се брои само в UX-01.

Композиция, ритъм и подравняване

На desktop началната има силен, почти цял екран hero, а contact/portfolio/process/calculator започват с нискоинформационна title лента, измерена на 200px височина. Project detail започва направо с ляво подравнено заглавие в белия content panel. Това не е грешка само по себе си, но бих направил разликата по-целенасочена: компактно заглавие за task pages като „Контакти“, по-изразително начало за портфолиото.

На mobile четирите статистики на home стоят в дълга вертикална колона преди услугите. Моето предпочитание е компактна 2×2 композиция, ако текстовете остават четими. Така доказателствата за работата ще идват по-рано, без да се намалява размерът на body текста. В portfolio и Lazur едноколонните галерии са разбираеми, но дълги; curated първа селекция и групиране по помещения биха дали по-добър ритъм. Не препоръчвам автоматично carousel вместо достъпна галерия.

Desktop featured grid на home оставя голяма празна зона под третата и четвъртата колона. Това се вижда в V03; CSS съчетава автоматичен брой колони с една карта, заемаща два реда. За мен композицията изглежда недобалансирана, не „счупена“. Бих пробвал голяма водеща карта плюс четири малки в подреден блок или равномерна grid. Това е визуална препоръка, не допълнителен defect ID.

Има няколко horizontal alignment линии: title wrapper x=99, content x=131, custom home x=148, featured grid x=196 при 1440px. Wide gallery и тесен prose container са полезни, но именувайте тези варианти. Дългите desktop редове в project introduction бих ограничил до по-комфортна prose ширина, без да стеснявам снимките.

Типография, cards и изображения

Oswald работи добре за строителния характер на бранда. Hero H1 е 83.2px desktop/41.6px mobile; inner H1 е 32px. По-малко убедителни са близките section стойности 24/25.6/27.2/28px без ясна роля. Бих ги свел до малка scale, а не сменял шрифтовете.

Home project cards са с radius 6px и скрити captions; portfolio показва постоянни overlay headings; process cards имат описание под снимката, border и radius 8px; calculator information cards също са 8px. Различните видове съдържание оправдават различни компоненти, но имената на проектите не трябва да зависят от мястото им в сайта. Разликата 6px/8px сама по себе си е дребна, не usability проблем.

Gallery thumbnails използват cover и различни ratios от оригиналните изображения. object-fit:cover изрязва при несъвпадащи пропорции.[8] В разгледания Lazur lightbox портретната снимка се показва с повече вертикален контекст; това е нормална разлика thumbnail/full view, не доказателство за лош crop. Не установявам системно изрязани важни детайли и не правя заключения за произхода или автентичността на изображенията.

5. Accessibility: конкретни числа, не обща оценка „минава“

UX-01 · Medium — контрастът е реалният най-ясен дефект

На mobile менюто на home активният „БГ“ почти изчезва върху тъмния drawer. Pixels и axe/computed colors се потвърждават взаимно:

• Активен „БГ“: #1c1c1a върху #090c10, 13px — 1.1481:1.
• Outline CTA върху бяло, например Facebook на „Контакти“: #c4a882, 18px normal — 2.2652:1.
• Footer headings: 3.8075:1; copyright: 3.1993:1.
• Малък accent text #8b7355: 4.4860:1 върху бяло и 4.0479:1 върху #f5f3ef.

За тези нормални текстове прагът на WCAG 2.2 SC 1.4.3 AA е 4.5:1; 4.4860 не трябва да се закръгля до pass.[1] Това е конкретно несъответствие, не въпрос на вкус. Не пренасям тези ratios върху фотографски backgrounds.

Разделете decorative accent от accent-text. Проверен пример за text accent е #765f43: 6.0202:1 върху бяло и 5.4323:1 върху светлата повърхност. За drawer #c4a882 върху #090c10 дава 8.6504:1; добавете и underline/друг нецветен active индикатор. Приемане: повторно измерване на normal/hover/focus/active и axe при отворено меню, не само на затворена страница.

UX-10 · Low — headings трябва да описват структурата

На home и „За нас“ статистически стойности като „36“, „1“ и „100+“ са H3 след H1. Construction/interior повтарят заглавието като H1 и H2. Heading navigation трябва да комуникира организацията на съдържанието.[5] Бих използвал текст или description list за числата и един смислен heading за блока. Самото прескачане на rank не е достатъчно за автоматично WCAG failure; скритият theme H1 „Начало“ също не е втори видим H1.

UX-13 · Low — Escape трябва да е последователен

В desktop „Портфолио“ dropdown Enter отваря, но Escape оставя подменюто видимо с aria-expanded=true. Втори Enter го затваря. Mobile Escape работи. Това не е keyboard trap, а поправима непоследователност. Приемане: Escape затваря desktop submenu и запазва/връща focus към toggle; Tab, Enter/Space и mouse behavior остават работещи.

Още полезни уточнения: има 34 axe runs, не „34 сертифицирани страници“. В отворения lightbox конкретният run няма violations. При 320 CSS px не е измерен document horizontal overflow в 13 routes, но това не замества 200/400% browser zoom или пълна Reflow проверка.[2] Видим keyboard focus е отделно изискване; native outline е отчетен в interaction тестовете и се вижда в FAQ кадъра, но не е визуално проверен върху всеки background.[3]

Проверените hamburger/lightbox controls са над 24×24px. 44px е добра продуктова цел, но не универсалният AA минимум; SC 2.5.8 има 24px праг и изключения за spacing/inline targets.[4] Повтарящият се alt „Апартамент Лазур“ не различава кадрите. Подобрете описанията според действителното информационно предназначение на всяка снимка, без автоматични измислени alt текстове.[6]

6. Security и privacy — какво е установено и какво не

Положителната основа е работещ HTTP→HTTPS redirect, успешно валидиран сертификат и TLSv1.3 в наблюдаваната връзка. В извадката няма HTTP mixed-content заявки. HTTPS language cookie има Secure и SameSite=Lax; не е authentication cookie. Обикновеният несъществуващ URL връща истински 404 без видим stack trace. Това са добри наблюдения, не пълна гаранция за сигурност.

SEC-01 · Medium · включва UX-12 — по-малко външни зависимости, повече прозрачност

На home и „Контакти“ са наблюдавани опити за Google Fonts/Maps заявки преди действие. Security проверката е блокирала off-origin трафика: три Fonts и два Maps опита в три посещения. Не са инспектирани реалните Google response cookies. Картата е с loading=lazy, но това не я прави click-to-load; в проверените viewport-и заявката започва автоматично.

Maps iframe използва no-referrer-when-downgrade; подготвеният Referer съдържа пълния contact URL. Няма доказано изтичане на чувствителни query данни. no-referrer премахва Referer, а strict-origin-when-cross-origin ограничава cross-origin HTTPS случая до origin.[14]

В проверените навигации, съдържание и page sitemaps не е открита privacy информация. Това е ограничено отрицателно доказателство, не доказана липса на всеки възможен документ. Google документира, че Fonts API получава IP за обслужване/сигурност, но не задава или логва cookies и не използва тези данни за targeted advertising.[13] Следователно „има Google Fonts“ не означава „има рекламно проследяване“.

Препоръката е локални шрифтове след license проверка, карта след ясно действие и достъпна, конкретна privacy информация, включително за имейл запитванията. Приемане: преди действие няма Fonts/Maps HTTP заявки, след действие картата работи, Referer не носи path/query, policy link е откриваем. Нуждата от consent/banner се установява по реалните data flows и приложимите правила — тук няма GDPR заключение.

SEC-02 · Low — собствен HSTS и по-ранен redirect

HTTP root връща 301, но още plaintext отговорът задава езикова cookie без Secure. Проверените HTTPS отговори нямат собствен Strict-Transport-Security. HSTS казва на браузъра да използва HTTPS при бъдещи заявки; redirect сам по себе си е различен механизъм.[11] Възможна наследена/preloaded защита от родителския домейн не е проверена.

Изнесете redirect преди WordPress/cookies и въведете HSTS постепенно, с одобрен max-age. Не добавяйте механично includeSubDomains/preload. Приемане: HTTP redirect без Set-Cookie; HTTPS home/contact/service/404 с правилния header. Няма доказан credential leak или downgrade exploit.

SEC-03 · Low — CSP и anti-framing са hardening, не доказан XSS

На home, contact, service и 404 липсват CSP, CSP Report-Only и X-Frame-Options. Определете дали външното вграждане е нужно; frame-ancestors контролира кой може да embed-ва страницата.[12] Проверете и умишлените WordPress embed сценарии.

За по-широка CSP първо инвентаризирайте inline scripts/styles, Blob/Worker и origins, после Report-Only. Този режим генерира reports, но не блокира.[12] Приемане: одобрена enforced anti-framing policy и проверени менюта, езикови версии, галерия и карта преди по-широк enforcement. Липсващият header не доказва експлоатируема уязвимост.

SEC-04 · Low — последователен nosniff

REST index и oEmbed имат X-Content-Type-Options: nosniff; проверените HTML, 404 и navigation JS нямат. MIME types в извадката са правилни. OWASP препоръчва правилен Content-Type и nosniff срещу MIME sniffing.[10] Приемане: същата политика за HTML/static/error responses, без нови MIME blocking грешки. Това е Low hardening, не демонстрирана атака.

SEC-05 · Informational — security.txt е опция

Стандартният URL връща 404. По желание добавете обслужван канал за security сигнали, с Contact и Expires според RFC 9116.[16] Това не е уязвимост или самостоятелен launch blocker; по-важно е да има реален отговорник.

Публичните WordPress REST/oEmbed endpoints и version fingerprints не са автоматични vulnerabilities. WordPress описва публичния достъп до публично съдържание като нормален модел.[15] Asset ?ver= не удостоверява patch inventory. Не препоръчвам blanket REST disable. Не са проверявани login/admin, MFA, RBAC, CSRF, SQLi/XSS, uploads, backups или email delivery. Няма основание нито за „сайтът е пробит“, нито за „сайтът е сигурен“.

7. Съдържание, локализация и SEO

UX-07 · Low: от RU portfolio към проверения Lazur проект се сменят не само имената, а целият интерфейс и описанието към BG. Дайте RU summary на важните обекти или предупреждение за пълния езиков преход. Приемане: language context се запазва или смяната е изрична.

UX-09 · Low: BG менюто, галерията и 404 template съдържат „Toggle child menu“, „Enlarge“, „Close“, „Previous“, „Next“, „Search for:“. Локализирайте и accessible names, не само видимото меню. Проверете „АКРА Черномоец“ със собственика; редактирайте шаблонното „в ул.“ и неестественото „нула предавания“. Приемане: последователен език и реални, потвърдени имена на обектите.

UX-08 · Low: „Hello world!“ е публичен и sitemap-listed, с default WordPress текст, примерен comment и comment form. Ако блог не е нужен, премахнете sample съдържанието и ненужното коментиране по нормалния CMS lifecycle. Приемане: няма default post в sitemap и е избран правилен 404/410 или подходящ redirect. Формата не е изпращана; не е доказан spam/backend проблем. Тя е отделна от липсващата inquiry form на contact.

noindex, nofollow е активен в проверените HTML responses и вероятно е умишлен за BUILD/STAGING. Не го броя автоматично като SEO провал. Преди production собственикът трябва да потвърди домейна и намерението: тогава проверете indexability, canonical, sitemap, езикови еквиваленти и уникални page titles/descriptions. Не премахвайте noindex на development host само заради този доклад; той не е access control.

8. Практичен ред за работа и критерии за готовност

1. Поправете UX-02, VIS-01 и UX-01: destination на hero CTA, постоянни project names, contrast tokens. Готово означава проверени destinations, видими captions без hover и измерен контраст на реалните surfaces/states.
2. Уеднаквете Button variants и contact wording; обозначете калкулаторите като бъдещи, поправете Escape и системните преводи. Готово означава последователни desktop/mobile interactions, не само еднакъв CSS цвят.
3. Изчистете sample съдържанието и доработете най-важните услуги и case studies. Готово означава проверени фирмени факти, контекст и next-step CTA, без placeholders и измислени обещания.
4. Направете privacy inventory; локализирайте fonts, изведете карта след действие и публикувайте точна информация. Готово означава проверени network/storage поведения в разрешена среда, не просто видим банер.
5. Въведете HSTS/anti-framing/CSP/nosniff с rollout и regression checks. Паралелно определете update/backup отговорник. WordPress подчертава редовните updates и възстановяването като част от поддръжката.[18]
6. Повторете маршрутите и states при 1440/390/320/768px, плюс истински iOS/Android/Safari, screen reader и 200/400% zoom. Проверете gallery, drawer, dropdown, FAQ, focus и captions. Contact delivery се тества само с отделно разрешен сценарий.

Не бих добавял online form или нови зависимости само за да изглежда сайтът „по-професионален“. Ако се добавят state-changing функции, backend CSRF/authorization проверките стават отделна работа; OWASP изисква защита на такива заявки и предупреждава GET да не променя състояние.[17]

9. Въпроси, на които собственикът трябва да отговори

• Това staging ли е и кой е крайният production домейн? Кой одобрява публикуването?
• Кои услуги са най-важни за бизнеса и кои проекти ги доказват най-добре?
• Какъв е действителният обхват на участието във всеки case study? Има ли права за публикуване на снимките и клиентското съдържание?
• Актуални ли са „100+“, удостоверенията, срокът за отговор и FAQ обещанието „24 месеца гаранция за всички СМР“? Последното иска проверка по вид работа/договор, не правно заключение от този audit.
• Кой обработва имейлите, колко се пазят данните и кои доставчици имат достъп? Има ли други analytics/integrations извън извадката?
• Има ли проверен runtime inventory, MFA/least privilege, update процес и успешен restore test? Това са unknowns, не установени пропуски.

10. Обхват, метод и ограничения

Открити са 79 уникални routes. Посетени са 18 от тях плюс един синтетичен 404: общо 19 desktop-tested routes; 13 имат mobile и 320/768px spot checks. Проектната извадка е 5 от 27 BG и 1 от 27 EN. Има 69 реални screenshots и 34 axe runs. Основните BG страници са проверени, EN/RU са извадкови. Discovery не означава тестван route.

Към DOM/interaction проверките е добавен успешен native visual review на 17 различни screenshot файла от 6 routes, с 10 увеличени region crops за конкретни секции. Home, contact и Lazur са разгледани и desktop, и mobile; допълнително portfolio/process/calculator, mobile menu, FAQ и lightbox. Заснет файл не е автоматично визуално инспектиран файл. Дългите captures са използвани за композиция, а дребните детайли — само след crop.

Проверките са в изолирани Chromium contexts: основно 1440×900 и 390×844, axe-core 4.10.3. Не са реални телефони/Safari; няма screen-reader сесия или browser-UI zoom. Lab performance snapshots без throttling не са field Core Web Vitals, INP или Lighthouse score; не давам реален performance рейтинг. Security извадката включва публични GET/HEAD, headers, DOM/network interception и един TLS handshake, не пълната OWASP WSTG методология.[9]

Няма изпратени форми, коментари, обаждания или имейли, няма login, payloads, scans или промени по сайта. Maps е блокиран от audit scope; празното/неуспешно iframe съдържание в capture не е сайтова находка. Проверените tel href имат валиден формат „+ и цифри“; няма доказателство за счупени телефонни links, но dial behavior не е тестван.

Това е live snapshot, не repository commit. Техническите references по-долу са прочетени от запазените source текстове на проверките от същия ден; цитатите са сверени с тях, без претенция за ново външно retrieval. Измерванията, DOM наблюденията и визуалните мнения са различни видове доказателство. Нищо описано като поправка не е приложено към сайта.

11. Приложение: ориентири към доказателствата

HTML версията съдържа избрани изображения с captions. Файловите имена тук са за проследимост, не са нужни за разбирането на основните изводи.

• V01 — home-desktop-viewport.png: силен hero и видимият основен CTA, UX-02.
• V02 — home-mobile-viewport.png: responsive hero и stacked действия.
• V03 — home-desktop-1440x900.png, region x95/y1860–x1345/y2600: featured grid, липсващи видими captions и празна зона, VIS-01.
• V04 — home-mobile-390x844.png, region x0/y3000–x390/y4300: същите project cards без имена на mobile, VIS-01.
• V05 — portfolio-mobile-390x844.png, region x0/y0–x390/y1350: постоянни overlay заглавия за сравнение.
• V06 — home-mobile-menu-open.png: активен „БГ“, UX-01.
• V07 — project-lazur-mobile-390x844.png, горна и крайна секция; project-lazur-desktop-1440x900.png: case study, UX-04.
• V08 — project-lazur-mobile-lightbox-second.png: съществуващият lightbox.
• V09 — contact-mobile-390x844.png и contact-desktop-viewport.png: cards/CTA, UX-05/UX-11. Картата е изключена от визуалната оценка.
• V10 — process-mobile-faq-open.png, region x0/y3500–x390/y4800: answers и видим focus; отвореното състояние е създадено за теста, не е default.
• V11 — calculator-desktop-1440x900.png и mobile counterpart: placeholder cards, UX-06.

Числови/interaction доказателства: contrast-calculations.json, menu-axe-mobile.json, verification.json, interactions.json, route-specific desktop/mobile DOM snapshots. Security: browser-observation.json, http-redirect.json, homepage.json, contact.json, rest-index.json, navigation-js.json, tls.json, security-txt.json. SHA256 manifest фиксира финалния пакет.

Избрани визуални доказателства

Изрязани секции от реалните captures, без промяна на съдържанието. Всички изображения са вградени; не се зареждат от сайта.

Sources

1. [1] Understanding Success Criterion 1.4.3: Contrast (Minimum) | WAI | W3C
   https://www.w3.org/WAI/WCAG22/Understanding/contrast-minimum.html
2. [2] Understanding Success Criterion 1.4.10: Reflow | WAI | W3C
   https://www.w3.org/WAI/WCAG22/Understanding/reflow.html
3. [3] Understanding Success Criterion 2.4.7: Focus Visible | WAI | W3C
   https://www.w3.org/WAI/WCAG22/Understanding/focus-visible.html
4. [4] Understanding Success Criterion 2.5.8: Target Size (Minimum) | WAI | W3C
   https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html
5. [5] Headings | Web Accessibility Initiative (WAI) | W3C
   https://www.w3.org/WAI/tutorials/page-structure/headings
6. [6] Images Tutorial | Web Accessibility Initiative (WAI) | W3C
   https://www.w3.org/WAI/tutorials/images
7. [7] <a> HTML anchor element - HTML | MDN
   https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/a
8. [8] object-fit CSS property - CSS | MDN
   https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/object-fit
9. [9] OWASP Web Security Testing Guide | OWASP Foundation
   https://owasp.org/www-project-web-security-testing-guide
10. [10] HTTP Headers - OWASP Cheat Sheet Series
    https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html
11. [11] Strict-Transport-Security header - HTTP | MDN
    https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Strict-Transport-Security
12. [12] Content Security Policy (CSP) - HTTP | MDN
    https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP
13. [13] Frequently Asked Questions - Google Fonts
    https://fonts.google.com/faq
14. [14] <iframe> HTML inline frame element - HTML | MDN
    https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/iframe
15. [15] REST API Handbook | Developer.WordPress.org
    https://developer.wordpress.org/rest-api
16. [16] RFC 9116: A File Format to Aid in Security Vulnerability Disclosure
    https://www.rfc-editor.org/rfc/rfc9116.html
17. [17] Cross-Site Request Forgery Prevention - OWASP Cheat Sheet Series
    https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html
18. [18] Hardening WordPress – Advanced Administration Handbook | Developer.WordPress.org
    https://developer.wordpress.org/advanced-administration/security/hardening