Bir kurumsal web sayfası açıldığında ziyaretçinin ihtiyacı çoğu zaman basittir: hizmetin ne olduğunu öğrenmek, doğru iletişim yolunu bulmak, bir belgeye ulaşmak veya talebini iletmek. Sayfanın bazı parçaları JavaScript ile zenginleştirilebilir; ancak ana metin, temel bağlantılar ve önemli iletişim yolu yalnızca betikler başarıyla yüklendiğinde görünüyorsa küçük bir ağ kesintisi bile görevi durdurabilir. Bu rehber, web tasarımında temel içeriği önce sunup etkileşimleri bunun üzerine ekleme yaklaşımını ve betik yüklenmediğinde ne olacağını sınama yöntemini açıklar. Kuzguncuk’ta belirli bir işletmenin teknik yapısı ya da sonucu hakkında iddia içermez.

Temel görevi ve geliştirmeyi birbirinden ayırın

Bir sayfanın her özelliği aynı öneme sahip değildir. Ziyaretçinin hizmeti anlaması, iletişim bilgisine erişmesi veya ana sayfaya dönebilmesi çoğu kurumsal sitede temel görevlerdir. Açılır grafik, anlık filtre, animasyon ya da kişiselleştirilmiş öneri ise bu görevleri kolaylaştıran geliştirmeler olabilir. Tasarım başlamadan önce ekip, hangi bilginin herkes için ilk HTML yanıtında bulunması gerektiğini ve hangi etkileşimin ek deneyim sunduğunu yazılı hâle getirmelidir.

Bu ayrım, etkileşimli bileşenleri kaldırma çağrısı değildir. JavaScript; menü, arama, filtre, doğrulama ve dinamik güncelleme gibi işlevleri değerli kılabilir. Sorulması gereken, bu işlevin yüklenmemesi durumunda kullanıcının hangi asgari bilgiye ve alternatife sahip olacağıdır. Örneğin filtreli bir liste hiç sonuç göstermiyorsa, kullanıcıya kategori sayfasına veya tam listeye giden normal bir bağlantı verilebilir. Bir açılır panelin içindeki tek telefon numarası, e-posta veya hizmet açıklaması temel bilgi ise bu bilgi betiğe bağımlı saklanmamalıdır.

Progressive enhancement, önce temel ve anlamlı deneyimi kurup tarayıcı yetenekleri mevcut olduğunda gelişmiş davranış ekleme yaklaşımıdır. MDN’nin kavram açıklaması bu katmanlı düşünceyi özetler; WHATWG HTML standardı da birçok formun istemci betiği olmaksızın HTML arayüzü ve sunucu işleme ile kurulabileceğini açıklar. Bu kaynaklar her projenin JavaScript olmadan bütünüyle çalışacağını garanti etmez. Tasarım kararı, sayfanın gerçek görevlerine ve kullanılan bileşenlere göre verilmelidir.

İçeriği ilk yanıtta anlamlı tutun

Bir ziyaretçi sayfaya doğrudan bir arama sonucu, e-posta veya kayıtlı bağlantı üzerinden gelebilir. Bu nedenle yalnız ana sayfanın çalışması yeterli kabul edilmemelidir. Her önemli sayfada başlık, kısa açıklama, ana hizmet içeriği, temel gezinme ve iletişim bağlantısı mümkün olduğunca normal HTML içinde bulunmalıdır. İçeriği sonradan boş bir kapsayıcıya JavaScript ile eklemek, betik indirilemediğinde ekranda anlamsız bir boşluk bırakabilir.

Normal bağlantıları koruyun

Bir menü öğesi başka bir sayfaya götürüyorsa, yalnızca tıklama olayına bağlanmış görsel bir kutu yerine gerçek bir bağlantı kullanın. Böylece bağlantı yeni sekmede açılabilir, adresi kopyalanabilir ve klavye ile çalıştırılabilir. JavaScript, tıklamayı daha akıcı hâle getirebilir; fakat hedef adresi ve temel gezinme anlamını ortadan kaldırmamalıdır. Eylem bir gönderim yapıyorsa uygun bir form ve düğme semantiği tercih edilmelidir.

Menü betiği yüklenmediğinde ana bölümlere erişim için sade bir gezinme alanı bırakın. Menü düğmesi yalnızca paneli açmakla kalmamalı; açık/kapalı durumunu belirtmeli ve odak sırasını beklenmedik biçimde değiştirmemelidir. Ancak bu rehber ayrıntılı klavye erişilebilirliği veya uyumluluk belgesi değildir; etkileşimli menüler ayrıca yardımcı teknoloji ve klavye ile test edilmelidir. Daha geniş kontroller için web erişilebilirliği kontrolleri rehberine bakılabilir.

Formlarda betiksiz bir geri dönüş planlayın

HTML formu, alanları ve gönderim hedefini tarif edebilir; sunucu girdileri doğrulayabilir ve sonucu yeni bir sayfada gösterebilir. İstemci tarafı doğrulama, alanın yanında hızlı ipucu vermek bakımından yararlıdır ama tek güvenlik veya doğruluk denetimi olmamalıdır. Tarayıcı betiği çalışmıyorsa formun gönderilememesi yerine, sunucunun aynı girdileri denetleyip anlaşılır hata mesajı döndürmesi değerlendirilebilir. Gerçek uygulama; veri hassasiyeti, iş akışı ve güvenlik gereksinimleriyle birlikte tasarlanmalıdır.

Form hatasında kullanıcıya hangi alanın düzeltileceği söylenmeli; geçerli alanların içeriği mümkün olduğunca korunmalıdır. Sunucu yanıtı hata verdiyse, tekrar deneme yolu görünür olmalı ve aynı talebin iki kez işlenmesi gibi riskler ayrıca ele alınmalıdır. “Gönderildi” mesajını yalnızca tarayıcıdaki bir tıklama animasyonuna bağlamak doğru değildir; yanıtın gerçekten alınıp alınmadığı açıkça belirtilmelidir. Form tasarımının alan seçimi, hata ve doğrulama adımları için web sitesi form tasarımı rehberiyle birlikte ilerleyin.

Betiksiz senaryoda formun güvenli biçimde çalıştırılması mümkün değilse, bunu gizlemek yerine kullanıcıya nedenini ve alternatif kanalı bildirin. Örneğin ödeme veya kimlik doğrulama gibi hassas bir süreç, özel bir teknik akış gerektirebilir. Böyle bir akışın kapsayıcı ve güvenli olması uzman incelemesi ister. Bu yazı belirli bir uyumluluk, güvenlik sertifikası veya hukuki uygunluk vaadi vermez; yalnızca başarısız betik durumunu tasarım ve kabul planına dâhil etmeyi önerir.

İşlevi katmanlara göre planlayın

Her kritik sayfa için küçük bir işlev tablosu hazırlayın. İlk sütuna kullanıcının görevini, ikinciye görev için gerekli içeriği, üçüncüye isteğe bağlı zenginleştirmeyi, son sütuna ise zenginleştirme başarısız olursa sunulacak geri dönüşü yazın. “Hizmeti bul” görevinde temel bağlantı, sayfa başlığı ve açıklama gerekir; canlı arama önerisi ek kolaylık olabilir. “Ulaşım bilgisini gör” görevinde doğrulanmış adres metni ve doğrudan iletişim yolu temel olabilir; harita bileşeni yalnızca ek bağlam sunabilir.

Geri dönüş, bozuk sayfa veya uyarı yığını oluşturmamalıdır. Kullanıcıya çalışan seçenekleri sunmalı, başarısız özelliği abartmamalı ve yeniden deneme kararını kullanıcıya bırakmalıdır. Bir harita yüklenmezse adres metni ve kullanıcı tarafından doğrulanmış yön tarifi bağlantısı bulunabilir. Bir takvim bileşeni açılmazsa iletişim formu veya telefon bilgisi sunulabilir. Bu senaryolar her iş kolunda aynı değildir; yanlış ya da güncel olmayan bilgi vermemek için adres, saat ve iletişim bilgisi içerik sahibi tarafından doğrulanmalıdır.

İsteğe bağlı özellikleri aşamalı eklerken, temel görev için gerekli olmayan kütüphane veya uzak servisleri kritik içeriğin önüne koymayın. Ağdan alınan bir betik hiç yanıt vermeyebilir, çok geç gelebilir veya tarayıcı tarafından engellenebilir. Geliştirme ekibi hata anında hangi bileşenin durduğunu görmeli; ziyaretçi ise tanılama ayrıntılarına boğulmamalıdır. Kullanıcı arayüzündeki uyarı kısa ve eyleme dönük, teknik kayıtlar ise bakım ekibinin tanılayabileceği ölçüde ayrıntılı olabilir.

Betik kapalı ve yavaşken kabul testi yapın

Yayın kontrolünü yalnızca normal ağ ve açık JavaScript ile tamamlamayın. Test ortamında JavaScript’i kapatın veya geliştirici araçlarıyla belirli bir betik isteğini engelleyin. Önce ana sayfayı, sonra doğrudan önemli bir alt sayfayı açın. Başlıklar ve ana içerik görünüyor mu? Gezinme ve iletişim yolu bulunabiliyor mu? Formun sunucu yanıtı anlaşılır mı? Boş bir alan, anlamsız düğme veya kapanmayan yükleniyor mesajı var mı? Gözlemleri cihaz, tarayıcı, sayfa adresi ve test koşuluyla not edin.

İkinci turda betikleri açık tutup yavaş ağ veya gecikmeli yanıt senaryosu kullanın. İçerik gelene kadar sayfa zıplıyor mu, düğme yanlış zamanda kullanılabilir oluyor mu, üst üste gönderim mümkün mü? Bir filtre beklerken tüm sayfayı kilitlemek yerine kullanıcıya mevcut listeyi sunmak daha uygun olabilir. Bu testler hız puanı ya da sıralama sonucu üretmek için değil, görev kesintisini ve belirsiz durumu bulmak içindir. Her gözlemde sorunun hangi katmanda başladığını ayırın: içerik sunumu, ağ isteği, istemci davranışı veya sunucu yanıtı.

Kontrol listesini gerçek sayfa türlerine göre çeşitlendirin: hizmet, iletişim, duyuru, içerik arşivi ve varsa işlem sayfası. Her sayfada aynı betiksiz davranışı varsaymayın. Bir içerik sayfasında normal bağlantılar yeterliyken, özel bir uygulamada temel görev için etkileşimli kod gerekebilir. Böyle bir durumda yükleme ve hata durumu açıkça tasarlanmalı; kullanıcıya işin tamamlanıp tamamlanmadığı söylenmelidir. canlıya geçmeden önce kullanıcı turu, bu senaryoların normal yayın kontrolüne eklenmesine yardımcı olur.

Bakım ve içerik sahipliğini belirleyin

Geliştirme sonrasında yapılan değişiklik, daha önce çalışan geri dönüşü bozabilir. Bu nedenle kabul senaryoları yeniden kullanılabilir olmalı. Bir değişiklik ana gezinmeyi, form yanıtını veya içerik kaynağını etkiliyorsa hem normal akış hem hata akışı tekrar denenmelidir. Testin başarılı olması, her cihaz ve ağ koşulunun kusursuz olduğunu kanıtlamaz; kapsamı ve gözlenen koşulları raporda açıkça yazın. Erişilebilirlik, güvenlik ve performans gibi ayrı uzmanlık alanlarını tek bir “betiksiz test” sonucuna indirgemeyin.

Site planlaması ve geliştirme kapsamı, bu katmanların birlikte düşünülmesini sağlar. web tasarım ve yazılım hizmeti sayfasında proje yaklaşımını inceleyebilir; içerik ve bakım süreçlerini de ilgili ekiplerle netleştirebilirsiniz. Bu bağlantı hizmet hakkında bilgi verir; belirli bir sonuç veya süre taahhüdü değildir.

Sık Sorulan Sorular

Bir web sitesinin JavaScript olmadan tamamen çalışması zorunlu mudur?

Her site ve özellik için tek bir zorunlu yöntem yoktur. Temel içeriğin ve ana görevin hangi koşullarda sunulacağı proje gereksinimine bağlıdır. Betik kapalı test, önemli içeriğin gereksiz yere saklanıp saklanmadığını anlamaya yarar; tüm etkileşimlerin birebir korunacağı anlamına gelmez.

Progressive enhancement ne demektir?

Önce anlamlı temel içerik ve işlevi kurup, tarayıcı yetenekleri mevcut olduğunda deneyimi geliştirmektir. Bu yaklaşım betikleri kullanmamak değil, kritik görevi tek bir istemci betiğinin başarılı yüklenmesine bağlamadan katmanlı tasarlamaktır.

JavaScript kapalıyken hangi sayfaları test etmeliyim?

Ana sayfanın yanı sıra kullanıcıların doğrudan açabileceği hizmet, iletişim, içerik arşivi ve işlem sayfalarını seçin. Test kümesini ziyaretçi görevlerine göre belirleyin; aynı senaryo her sayfa türüne uymaz. Bulguları sayfa ve koşulla birlikte kaydedin.

Formlar betik olmadan gönderilebilir mi?

HTML formu ve sunucu tarafı işleme bazı formların istemci betiği olmadan çalışmasını sağlayabilir. Ancak her uygulama için uygun olup olmadığı güvenlik, doğrulama ve iş akışına bağlıdır. Betik kontrolleri sunucu doğrulamasının yerine geçmemelidir.

Betik yüklenemezse kullanıcıya ne göstermeliyim?

Önce hangi temel görevin etkilendiğini belirleyin. Çalışan bir bağlantı, alternatif iletişim yolu veya tekrar deneme seçeneği sunun. Belirsiz bir hata kodu ya da süresiz yükleniyor göstergesi yerine kısa, doğru ve eyleme dönük açıklama kullanın.

Sunucu tarafında oluşturma bütün sorunları çözer mi?

Hayır. İlk HTML yanıtı içeriğin sunulmasına yardımcı olabilir; bazı etkileşimler yine istemci kodu gerektirir. Sayfanın görünürlüğü, hata davranışı, erişilebilirliği ve gerçek kullanıcı görevi ayrıca test edilmelidir.

Betikleri kapalı test etmek erişilebilirlik denetimi yerine geçer mi?

Hayır. Bu test yalnızca belirli bir hata ve içerik dayanıklılığı koşulunu inceler. Klavye kullanımı, ekran okuyucu, kontrast, yapı ve diğer erişilebilirlik kontrolleri kendi yöntemleriyle ele alınmalıdır.

Her özelliğe betiksiz bir alternatif hazırlamak gerekir mi?

Öncelik, temel görevlerin ve gerekli bilgilerin korunmasıdır. İsteğe bağlı görsel veya etkileşimli zenginleştirmelerin birebir alternatifi her zaman anlamlı olmayabilir. Özellik başarısız olduğunda kullanıcıyı yanıltmayan bir durum ve gerekiyorsa çalışan bir sonraki adım belirleyin.

Test raporuna “başarılı/başarısız” dışında kararın dayanağını da yazın: hangi görev denendi, betik hangi koşulda engellendi, hangi içerik ilk HTML’de bulundu ve ziyaretçiye hangi alternatif kaldı? Bu ayrıntı, ekiplerin küçük bir görsel kusuru ile kullanıcının işi tamamlayamamasını birbirinden ayırmasına yardım eder. Bir sonraki düzeltme böylece tahmine değil, tekrar edilebilir gözleme dayanır.