# TD-054 · Öneriyi ve değişikliği ekran okuyucuya duyur AI bir öneri getirdiğinde ya da metni değiştirdiğinde ekranda beliren işaret ekran okuyucuya ulaşmıyor. Öneriyi ve değişikliği odağı oynatmadan, yeriyle ve eski hâliyle sesli duyurmak görmeyen kullanıcıyı işin içinde tutar. - Adres: https://tandem.komunite.com.tr/desen/oneriyi-ve-degisikligi-ekran-okuyucuya-duyur - Yer: Çalışırken > Kontrol - Seviye: Temel. Her AI özelliğinde olmalı. - Son inceleme: 27 Ekim 2026, Komünite editörlüğü ## 30 saniyede dene 1. İşletim sisteminin ekran okuyucusunu aç (macOS'ta VoiceOver, Windows'ta Ekran Okuyucusu ya da NVDA) ve ekrana bakmadan ürünündeki AI özelliğini kullan. 2. Bir metin yaz ve AI'dan bir düzeltme ya da öneri iste. Öneri geldiğinde ekran okuyucu bir şey söylüyor mu? 3. Öneriyi kabul et. Ekran okuyucu neyin ve nerede değiştiğini söylüyor mu, yoksa yalnız imlecin durduğu satırı mı okuyor? 4. AI çalışırken, bitirince ve senden onay beklerken ne duyduğunu not et. Bu üç durumu sesten ayırt edemiyorsan bu desen ürününde eksik. ## Sorun Kullanıcı ekran okuyucuyla bir müşteri e-postası yazıyor. Cümleyi bitirip bir sonrakine geçerken asistan yazım denetimi yapıyor. Bir yazım hatasını düzeltiyor, teslim süresini anlatan cümleyi de daha resmî olsun diye yeniden yazıyor. Gören bir kullanıcı ekranın köşesinde küçük bir rozet ve metnin içinde renklenen iki yer görür. Ekran okuyucu kullanıcısı hiçbir şey duymuyor. Odak yazı kutusunda, imleç olduğu yerde. Kullanıcı yazdığı metni biliyor ya da bildiğini sanıyor. Asistan metni değiştirdiği anda bu bilgi eskiyor. Değişikliği bulmanın tek yolu bütün metni baştan dinlemek. Kullanıcı e-postayı gönderiyor, müşteri kullanıcının hiç yazmadığı bir teslim süresini okuyor. Satır içi öneri de aynı yerden kırılıyor. Hayalet metin ekranda soluk bir satır olarak beliriyor. Duyurulmazsa kullanıcı onun orada olduğunu bilmiyor. Bazı editörlerde Tab hem gezinmenin hem kabulün tuşu, o yüzden kullanıcı varlığını bilmediği bir öneriyi kazara kabul edebiliyor. Duyurulmayan bir değişiklik, ekran okuyucu kullanıcısı için ancak bir hata olarak geri döndüğünde ortaya çıkıyor. ## Neden atlanıyor AI özellikleri görsel bir dille tasarlanıyor: soluk hayalet metin, renkli alt çizgi, üstü çizili eski kelime, beliren bir rozet. Bu işaretlerin hiçbiri kendiliğinden ses çıkarmıyor. Ekip ekranda gördüğü değişikliği herkesin gördüğünü varsayıyor. İkinci neden AI arayüzünün hızı. Öneri yazarken beliriyor, cevap parça parça akıyor, ajan arka planda dosya değiştiriyor. Her saniye bir şey oluyor ve hangisinin duyurulacağına karar vermek bir tasarım işi. Karar verilmeyince ya hiçbir şey duyurulmuyor ya da her şey. Ekran okuyucuyla kod yazan programcılarla yapılan bir çalışmada ajan, kullanıcının onayını beklerken önce “Action required: Run command in terminal” dedi, ardından [“Progress” demeyi sürdürdü](https://arxiv.org/abs/2506.13270). Bir katılımcı komutu şimdi kendisinin mi çalıştırması gerektiğini sordu. Üçüncü neden test. Ekipler AI özelliğini ekrana bakarak dener, ekran okuyucuyla deneme sürüm listesine girmez. Otomatik erişilebilirlik taramaları sayfanın o anki hâline bakar ve bir önerinin belirdiği anda duyurulup duyurulmadığını göremez. ## Desen AI bir öneri getirdiğinde ya da bir şeyi değiştirdiğinde bunu ekranda gösterdiği gibi sesle de söyler. Duyuru odağı yerinden oynatmaz, kullanıcının işini kesmez ve neyin, nerede değiştiğini söyler. 1. **Durum mesajını canlı bölgeye yaz.** Öneri, değişiklik ve AI'ın durumu `role="status"` ya da `aria-live="polite"` taşıyan, sayfa açılırken hazır duran bir bölgeye yazılır. Ekran okuyucu onu odak taşınmadan okur. 2. **Odağı yerinde bırak.** Öneri geldi diye imleci öneriye taşıma. Kullanıcı istediğinde bir kısayolla öneriye gider, işi bitince yazdığı yere döner. 3. **Neyin, nerede, neyden neye değiştiğini söyle.** “Güncellendi” yetmez. Duyuru yeri (paragraf, cümle, satır, dosya), eski hâli ve yeni hâli söyler. Renkle, üstü çiziliyle ve simgeyle verilen her bilgi metne de dökülür. 4. **Sırasını bekle.** Rutin duyuru kibar bölgeye gider. Kullanıcıyı kesen duyuru yalnız hata, veri kaybı ve onay bekleyen durumlar için kullanılır. 5. **Üç durumu ayır.** “Çalışıyor”, “bitti” ve “senden onay bekliyor” farklı duyurulur. Onay bekleme duyurusu sonraki ilerleme sesleriyle ezilmez. 6. **Kabulü ve geri almayı da duyur.** Kullanıcı bir öneriyi kabul ettiğinde ya da geri aldığında sonuç da söylenir: “Öneri 1 uygulandı. Geri almak için Ctrl+Z.” Bu kuralların zor kısmı seçim: ekrandaki değişikliklerden hangisinin kullanıcının bilmesi gereken bir değişiklik olduğuna karar vermek. Metnin anlamını değiştiren her şey o listededir. ## Önce ve sonra Aynı e-posta, iki ayrı asistanla. Soldaki cümleyi değiştirip köşeye bir rozet koyuyor ve ekran okuyucu sessiz kalıyor. Sağdaki değişikliği öneri olarak tutuyor, kullanıcı cümlesini bitirince kibar bir duyuruyla haber veriyor, her öneriyi yeriyle, eski ve yeni hâliyle okutuyor ve kabulü de duyuruyor. Örnek ekran (kurgusal): Kullanıcı ekran okuyucuyla bir müşteri e-postası yazıyor. Asistan yazım denetimi yaparken teslim süresini anlatan cümleyi de yeniden yazıyor. ### Önce: E-posta · yeni ileti - Yazı kutusu: Merhaba Ayşe Hanım, siparişiniz beş iş günü içinde kargoya verilecektir. İyi günler dilerim. - Bilgi: rozet · asistan 2 düzeltme yaptı - Bilgi: ekran okuyucu · “Düzenleme alanı, Merhaba Ayşe Hanım…” - Düğmeler: Gönder 1. Asistan cümleyi değiştirip köşeye küçük bir rozet koyuyor. Odak yazı kutusunda kaldığı için ekran okuyucu rozeti hiç okumuyor. 2. Kullanıcı “üç gün içinde” yazdığını sanıyor, e-posta “beş iş günü” diye gidiyor. Değişikliği bulmanın tek yolu bütün metni baştan dinlemek. ### Sonra: E-posta · yeni ileti - Yazı kutusu: Merhaba Ayşe Hanım, siparşiniz üç gün içinde kargoda olacak. İyi günler dilerim. - Bilgi: ekran okuyucu, cümle bitince · “Asistanın 2 önerisi var. İncelemek için Alt+F2.” - Adım (bekliyor): Öneri 1 / 2 · paragraf 1, cümle 1 · anlamı değiştiriyor · “üç gün içinde kargoda olacak” yerine “beş iş günü içinde kargoya verilecektir” - Adım (bekliyor): Öneri 2 / 2 · yazım · “siparşiniz” yerine “siparişiniz” - Düğmeler: Kabul et · Reddet · Sonraki öneri - Bilgi: ekran okuyucu, kabulden sonra · “Öneri 2 uygulandı: siparişiniz. Geri almak için Ctrl+Z.” 1. Asistan metni kendiliğinden değiştirmiyor, öneri olarak tutuyor. Kullanıcı cümlesini bitirince kibar bir duyuruyla haber veriyor, odak yerinden oynamıyor. 2. Her öneri yerini, eski ve yeni hâlini sesle veriyor, anlamı değiştiren ayrıca işaretli. Kabul ve geri alma da duyuruluyor. ## Piyasada Visual Studio Code AI özellikleri için ayrı erişilebilirlik sinyalleri tanımlıyor. Cevap geldiğinde, kullanıcının bir işlem yapması gerektiğinde, imleç satır içi önerisi olan bir satıra geldiğinde ve [bir dosya sohbet düzenlemeleriyle değiştirildiğinde](https://code.visualstudio.com/docs/agents/reference/ai-settings) ayrı sesler çalıyor. Ajan değişikliklerini anlatan belge, farkı birleşik yama biçiminde sunan [Accessible Diff Viewer'ı](https://code.visualstudio.com/docs/agents/run/review-code-edits) klavye ve ekran okuyucu kullanıcılarına öneriyor. GitHub'ın ekran okuyucu rehberi Copilot'un satır içi önerileri için aynı yolu anlatıyor. Erişilebilirlik sinyalleri açıksa öneri geldiğinde [bir ses çalıyor ve ekran okuyucu öneriyi okuyor](https://accessibility.github.com/documentation/guide/github-copilot-vsc). Öneri Alt+F2 ile açılan erişilebilir bir görünümde satır satır incelenebiliyor. Rehber NVDA ve Windows için yazılmış. Microsoft'un Word'deki Copilot için yazdığı ekran okuyucu rehberi başka bir yol anlatıyor. Yeniden yazma önerileri metne doğrudan uygulanmıyor, bir iletişim kutusunda geliyor. Kullanıcı önerileri ekran okuyucunun tarama kipinde okuyor, içerik ancak Replace düğmesine basınca değişiyor. Sohbet bölmesi için rehber, ekran okuyucunun [taslak üretiminin durumunu duyuracağını](https://support.microsoft.com/en-us/topic/use-copilot-in-word-with-a-screen-reader-d6132416-993f-42d1-9c2c-4b84c112a9a5) yazıyor. İki yol var. Biri değişikliği sesle haber veriyor, öteki değişikliği kullanıcı onaylayana kadar metne uygulamıyor. ## Kanıt Bu desenin dayanağı bir standart. WCAG 2.2'nin AA düzeyindeki 4.1.3 başarı ölçütü, durum mesajlarının [rol ya da özelliklerle programatik olarak belirlenebilmesini](https://www.w3.org/TR/WCAG22/#status-messages) istiyor, öyle ki yardımcı teknoloji onları odak almadan kullanıcıya sunabilsin. WCAG durum mesajını bağlam değişikliği yaratmayan ve bir işlemin sonucu, uygulamanın bekleme hâli, bir sürecin ilerlemesi ya da hataların varlığı hakkında bilgi veren içerik değişikliği olarak tanımlıyor. AI'ın “2 öneri hazır”, “yazıyor”, “bitti”, “onayını bekliyorum” ve “öneri uygulandı” cümleleri bu tanıma giriyor. Metindeki değişikliğin kendisi bir durum mesajı sayılmaz, onu haber veren cümle sayılır. W3C'nin açıklama belgesi amacı da söylüyor: kullanıcıyı odak almayan önemli değişikliklerden [işini gereksiz yere kesmeden](https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html) haberdar etmek. WAI-ARIA 1.2 bunun aracını tarif ediyor. `role="status"` olan bir öğe kibar bir canlı bölgedir ve yazar bu öğenin [durum değişince odak almamasını](https://www.w3.org/TR/wai-aria-1.2/#status) sağlamalıdır. Kibar bölgedeki güncellemeyi ekran okuyucu [o anki cümlenin sonunda ya da kullanıcı yazmaya ara verdiğinde](https://www.w3.org/TR/wai-aria-1.2/#aria-live) okur. Aynı belge, kesinti kullanıcının işini bozabileceği için `assertive` değerinin yalnız kesinti zorunluysa kullanılmasını istiyor. İki çalışma boşluğun AI arayüzlerinde nerede açıldığını gösteriyor. Flores-Saviaga ve arkadaşlarının CHI 2025'te yayımlanan çalışmasında görme engelli geliştiriciler önerilerin bolluğundan yakındı ve “AI molası” istedi. Hiç görmeyen bir katılımcı Tab tuşuna bastıktan sonra bir öneriyi kazara kabul edip etmediğini sordu, gezinirken Tab kullandığı için bunun çok kolay olduğunu anlattı. Ekran büyüteci kullananlar ekranın büyüttükleri bölümüne baktıkları için, öneri görünür alanın dışında belirdiğinde [önerinin geldiğinden habersiz kaldı](https://arxiv.org/abs/2503.16491). Chen ve arkadaşları 16 kör ve az gören programcıyı iki hafta izledi. Katılımcılar değişiklikleri anlamakta zorlandı ve bu, önerileri kabul etme güvenlerini sarstı. Yazarların tasarım önerisi bu desenle örtüşüyor: değişikliğin [kapsamını, yerini ve içeriğini metin ya da ses ipuçlarıyla](https://arxiv.org/abs/2506.13270) erişilebilir kılmak. Bir katılımcı durum duyurularının kısa olduğunu, birini kaçırınca ne olduğunu bilemediğini söyledi. İki çalışma da nitel, küçük örneklemli ve kod editörleriyle sınırlı, ama buldukları boşluk standardın tarif ettiği yerde duruyor. ## Ölçüm - **Duyurusuz değişiklik.** AI'ın içeriği değiştirdiği ya da öneri getirdiği yolları say ve kaçının bir canlı bölgeye duyuru yazdığına bak. Hedef hepsi. - **Duyurunun içeriği.** Örneklenen duyurularda yerin, eski ve yeni hâlin geçme payı. “Güncellendi” gibi içeriksiz duyurular hata sayılır. - **Kazara kabul.** Kabulden hemen sonra geri alınan önerilerin payını, ürün ekran okuyucuyu algılıyorsa iki grup için ayrı ölç. Fark büyükse öneri duyurulmuyor ya da kabul tuşu gezinme tuşuyla çakışıyor. - **Kesinti.** assertive ya da alert ile yapılan duyuruların payı. Rutin öneriler bu payı büyütüyorsa kullanıcı gereksiz yere kesiliyor. - **Ekran okuyucuyla görev testi.** Ekran okuyucu kullanan katılımcılarla düzenli görev testi yap. AI bir değişiklik yaptıktan sonra kullanıcı neyin değiştiğini söyleyebiliyor mu? ## Ajanına ver Üç metin var. Denetim promptu AI'ın arayüzde öneri getirdiği, içerik değiştirdiği ve durum bildirdiği yerleri bulur. Bunların canlı bölgeyle duyurulup duyurulmadığını, odağın taşınıp taşınmadığını ve duyurunun ne söylediğini tarar, yalnız rapor yazar. Uygulama promptu sayfa açılırken hazır duran canlı bölgeleri, öneri ve değişiklikler için metin duyurularını ve AI'ın üç durumunu ayıran duyuruları ekler. Önce planı gösterir, onayınla uygular ve odağın yerinde kaldığını sınayan testler yazar. Kural kodlama ajanının arayüz kodu yazarken uyacağı alışkanlıklar için. ## Sınır Fazla duyuru da bir hata. Her harfte değişen bir öneriyi ya da akış hâlinde gelen cevabın her parçasını okutmak ekran okuyucuyu kullanılmaz hâle getirir. Kısa aralıkla gelen duyuruları birleştir, akan cevabı bitince tek seferde haber ver ve ayrıntıyı kullanıcının ayarına bırak. Duyuru sessiz değişikliği meşru kılmaz. Anlamı değiştiren bir düzenlemeyi önce uygulayıp sonra duyurmak, onu öneri olarak sunmaktan zayıf bir tasarım. Word'ün yolu, yani değişikliği kullanıcı onaylayana kadar metne uygulamamak, anlam değiştiren düzenlemelerde daha güvenli. Bu desen bir erişilebilirlik denetiminin yerini tutmaz. NVDA, JAWS, VoiceOver ve TalkBack gibi gerçek ekran okuyucularla ve onları her gün kullanan insanlarla deneme yapmadan duyurunun gerçekten okunduğunu bilemezsin. ## Promptlar ### Denetim promptu ``` Bu depoda AI'ın kullanıcıya öneri getirdiği ya da içeriği değiştirdiği bir arayüz var: satır içi tamamlama, yazım ve üslup önerileri, yeniden yazma, sohbet cevabı, dosya değiştiren bir ajan. Görevin, bu önerilerin, değişikliklerin ve AI'ın durum değişimlerinin ekran okuyucu kullanıcısına ulaşıp ulaşmadığını denetlemek. Hiçbir dosyayı değiştirme, yalnız rapor yaz. 1. AI'ın arayüze içerik eklediği, içeriği değiştirdiği ya da durum bildirdiği her yeri listele: öneri balonları, hayalet metin (ghost text), rozetler, toast bildirimleri, "yazıyor" göstergeleri, onay bekleyen düğmeler, sohbete gelen cevaplar, ajanın değiştirdiği dosyalar. 2. Her biri için bak: bir canlı bölge (aria-live="polite" ya da "assertive", role="status", role="alert", role="log") ya da platformun erişilebilirlik duyuru API'si kullanılıyor mu? Canlı bölge sayfa açılırken DOM'da hazır mı, yoksa içerikle birlikte mi ekleniyor (bazı ekran okuyucular sonradan eklenen bölgeyi duyurmaz)? 3. Duyuru metni ne söylüyor? Yalnız "güncellendi" mi, yoksa neyin, nerede, neyden neye değiştiğini mi? Yalnız renk, simge, üstü çizili ya da konumla verilen bilgi metne de dökülüyor mu? 4. Odak yönetimine bak: öneri ya da değişiklik gelince odak kendiliğinden taşınıyor mu? Kullanıcı Tab, Enter ya da ok tuşlarıyla gezinirken bir öneriyi farkında olmadan kabul edebilir mi? 5. assertive ya da role="alert" nerede kullanılıyor? Acil olmayan bir durumda kullanıcıyı kesiyor mu? Akış hâlinde gelen (streaming) cevap her parçada yeniden mi duyuruluyor? 6. AI'ın üç durumu (çalışıyor, bitti, kullanıcıdan onay bekliyor) duyuruda birbirinden ayrılıyor mu? Onay bekleme duyurusu sonraki ilerleme duyurularının altında kayboluyor mu? 7. Kabul, ret ve geri almadan sonra sonuç duyuruluyor mu? Fark görünümünün ekran okuyucuyla okunabilen bir metin hâli var mı? 8. AI anlamı değiştiren bir düzenlemeyi (sayı, tarih, ad, olumsuzluk) kullanıcı onaylamadan metne uyguluyor mu? Rapor biçimi: her bulgu için dosya ve satır, ne olduğu, ekran okuyucu kullanıcısına etkisi (örnek: asistan bir cümleyi değiştiriyor, değişiklik yalnız bir rozetle gösteriliyor, kullanıcı e-postayı değişikliği bilmeden gönderiyor) ve önerdiğin düzeltme. Önce içeriği sessizce değiştiren yerleri yaz. ``` ### Uygulama promptu ``` Bu depodaki AI arayüzüne "öneriyi ve değişikliği ekran okuyucuya duyur" desenini uygula. Önce planı göster, onayımı aldıktan sonra kodu değiştir. Hedef davranış: 1. Sayfa açılırken DOM'da hazır duran iki canlı bölge kur: rutin duyurular için role="status" (aria-live="polite"), yalnız acil durumlar için role="alert". Duyuruları tek bir yardımcı fonksiyonla bu bölgelere yaz. 2. AI bir öneri getirdiğinde odağı taşıma. Kibar bölgeye kısa bir duyuru yaz: kaç öneri olduğu ve nasıl inceleneceği ("Asistanın 2 önerisi var. İncelemek için Alt+F2."). 3. Her öneri ve değişiklik için okunabilir bir metin hâli üret: yer (paragraf, cümle, satır, dosya), eski hâl, yeni hâl. Renk, üstü çizili ve simgeyle verilen bilgiyi metne dök. Anlamı değiştiren önerileri (sayı, tarih, ad, olumsuzluk) duyuruda ayrıca belirt. 4. Anlamı değiştiren düzenlemeleri kullanıcı onaylamadan metne uygulama, öneri olarak tut. 5. Kabul, ret ve geri almadan sonra sonucu duyur ("Öneri 1 uygulandı. Geri almak için Ctrl+Z."). 6. AI'ın durumlarını ayrı duyur: çalışıyor, bitti, kullanıcıdan onay bekliyor. Onay bekleme duyurusunu sonraki ilerleme duyurularıyla ezme. Akış hâlinde gelen cevabı parça parça okutma, bitince tek bir duyuru yap ve cevabın tamamını erişilebilir bir görünümden okut. 7. Ayarlara bir duyuru ayrıntısı seçeneği ekle (kısa, ayrıntılı, kapalı). Uygularken: - assertive ve role="alert"i yalnız hata, veri kaybı ve onay bekleyen durumlar için kullan. - Aynı duyuruyu art arda tekrarlama, kısa aralıkla gelen duyuruları birleştir. - Bir test ekle: bir öneri üret, kibar canlı bölgenin metninin öneri sayısını ve inceleme yolunu içerdiğini, odağın yazı kutusunda kaldığını doğrula. İkinci test: bir öneriyi kabul et ve duyurunun yeri, eski ve yeni hâli içerdiğini doğrula. Mümkünse NVDA ya da VoiceOver ile elle de dene. ``` ### AGENTS.md kuralı ``` ## Değişikliği görmeyen kullanıcıya da söyle - Arayüze AI önerisi, durum ya da sonuç eklerken duyuruyu da yaz: sayfa açılırken hazır duran, role="status" ya da aria-live="polite" taşıyan bir bölgeye. - Duyuru için odağı taşıma. Odağı yalnız kullanıcı istediğinde taşı. - Duyuru neyin, nerede değiştiğini söylesin: yer, eski hâl, yeni hâl. "Güncellendi" tek başına yetmez. - assertive ya da role="alert"i yalnız hata, veri kaybı ve onay bekleyen durumlar için kullan. - Renk, simge ve konumla verdiğin bilgiyi metin olarak da ver. - Anlamı değiştiren bir düzenlemeyi kullanıcı onaylamadan uygulama, önce öneri olarak sun. ``` ## Kaynaklar 1. [Screen Reader Programmers in the Vibe Coding Era: Adaptation, Empowerment, and New Accessibility Landscape](https://arxiv.org/abs/2506.13270), arXiv (Chen, Qiu, Wang, Wang, Yang), Haziran 2025 2. [AI settings reference](https://code.visualstudio.com/docs/agents/reference/ai-settings), Microsoft (Visual Studio Code) 3. [Review and revert agent changes](https://code.visualstudio.com/docs/agents/run/review-code-edits), Microsoft (Visual Studio Code) 4. [Using GitHub Copilot in Visual Studio Code with a Screen Reader](https://accessibility.github.com/documentation/guide/github-copilot-vsc), GitHub 5. [Use Copilot in Word with a screen reader](https://support.microsoft.com/en-us/topic/use-copilot-in-word-with-a-screen-reader-d6132416-993f-42d1-9c2c-4b84c112a9a5), Microsoft 6. [Web Content Accessibility Guidelines (WCAG) 2.2, Success Criterion 4.1.3 Status Messages](https://www.w3.org/TR/WCAG22/#status-messages), W3C, 12 Aralık 2024 7. [Understanding SC 4.1.3: Status Messages (Level AA)](https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html), W3C Web Accessibility Initiative 8. [Accessible Rich Internet Applications (WAI-ARIA) 1.2, status role](https://www.w3.org/TR/wai-aria-1.2/#status), W3C, 6 Haziran 2023 9. [Accessible Rich Internet Applications (WAI-ARIA) 1.2, aria-live](https://www.w3.org/TR/wai-aria-1.2/#aria-live), W3C, 6 Haziran 2023 10. [The Impact of Generative AI Coding Assistants on Developers Who Are Visually Impaired](https://arxiv.org/abs/2503.16491), arXiv (CHI 2025, Flores-Saviaga, Hanrahan, Imteyaz, Clarke, Savage), Mart 2025 --- Kaynak: https://tandem.komunite.com.tr · Metin CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/deed.tr), promptlar ve kural MIT-0 (https://opensource.org/license/mit-0).